Misc AADS & X9.59 Discussions

AADS Postings and Posting Index,
next, previous - home

The end of P-Cards?
The end of P-Cards?
The end of P-Cards?
Who or what to authenticate?
Who or what to authenticate?
AGAINST ID CARDS
AGAINST ID CARDS
Erst-Freedom: Sic Semper Political Cryptography
XML vs. EDI
Rubber hose attack
Rubber hose attack
Rubber hose attack
Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
Rubber hose attack
3D Secure Vulnerabilities?
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack
when a fraud is a sale, Re: Rubber hose attack

FW: The end of P-Cards?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 10/02/2001 07:31 PM
To: David Goldberg <david.goldberg@xxxxxxxx>
cc: <anders.rundgren@xxxxxxxx>,
<internet-payments@xxxxxxxx>
Subject: Re: FW: The end of P-Cards?

the EDI 810, 820, etc formats that can be used by the previous example of the automobile industry ... being able to feed p-card transactions directly into backend a/p system ... are also standard format used in ACH bank network. An example is 3rd party bill processor doing funds transfer for single aggregate total with individual account remittence broken down into ACH addenda record using EDI defined format (i.e. just need to know how to get the data items into ACH ... some ACH addenda records can get quite large).

the x9.59 financial standard does provide for digital signature strong authentication for all account-based transactions (credit, debit, ach, check, stored-value, etc). reference recent ACH trials ...
https://www.garlic.com/~lynn/nacharfi.htm NACHA AADS RFI
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm NACHA AADS results!!

the design has strong authentication carried as part of the seemless, end-to-end single transaction (authorization business process also responsible for authentication business process w/o any major gaps and/or holes
https://www.garlic.com/~lynn/ ... misc. x9.59 financial standard issues.

misc. other nacha references
https://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
https://www.garlic.com/~lynn/aadsm6.htm#aadsatm (certificate-less) digital signatures can secure ATM card payments on the internet
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsmore.htm#nacha NACHA digital signature pilot
https://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
https://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
https://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set (authentication is the key)
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nacha Nacha reports mentions X9.59 payment protocol
https://www.garlic.com/~lynn/aepay7.htm#visadeb1 Visa Debit Card
https://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
https://www.garlic.com/~lynn/ansiepay.htm#aadsach NACHA to Test ATM Card Payments for Consumer Internet Purchases
https://www.garlic.com/~lynn/ansiepay.htm#atmdebit NACHA AADS ATM debit ... from tomorrow's american banker
https://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
https://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?

David Goldberg at 10/02/2001 08:36 AM wrote:
-Quick and efficient settlement: Banks, the subject of another email in this string, maintain an effective inter-bank clearing network, i.e. ACH and other country-specific networks, that is actually very efficient at moving money between bank accounts at different banks. Until there is a better solution, banks will continue to play a valuable intermediary role in the world's ability to move money. Commercial settlement solutions should leverage this strength. The real issue here is that the ACH network, albeit effective at moving dollars, is ineffective at moving the data associated with those dollars (see next point).

-Rich remittance information: One of the least efficient and costliest activities involved in B-to-B settlement is the time and resources it takes to generate payments on the buyer side and, even more so, post and reconcile payments on the seller side. Buyers and sellers both benefit significantly when remittance information and addenda records move with the payments through the system. The largest value-add for either participant would be the ability to include as much descriptive remittance as is required for more efficient back-office payment processing. Furthermore, the need to keep the "dollars and data" together from end-to-end is critical. Once separated, as happens with a fEDI transaction that flows into a bank for back-end ACH settlement, remittance information requires manual processing or re-keying. When bits turn into atoms and back again, errors inevitably occur. All you have to do is ask your nearest Account Receivable Manager or Controller about the remittance and reconciliation limits of ACH, fEDI, P-Cards and paper checks.

-Integration with existing A/P and A/R systems: The sheer number of various ERP systems currently installed within enterprises, and the systems-related investment constraints of mid-sized and small businesses, seem to leave only paper checks as the only ubiquitous payment solution. However, given the remittance, security/fraud and settlement timing issues associated with checks, buyers and sellers need an electronic payment solution that is acceptable and usable by companies of all sizes. Therefore, the ability of any payment and settlement application to integrate into these systems and software, without necessitating changes to those systems, makes remittance flow and reconciliation even more efficient. A buyer should be able to generate their regular pay run within their existing A/P system environment and process, include addenda in the proscribed format of that system and disburse it electronically to all of its vendors regardless of vendor size, systems capabilities or preferred remittance format. Likewise, a seller should be able to receive remittance in their A/R system's proscribed format for electronic uploading and posting, from any of its business customers regardless of size, systems capabilities, etc.

-Security: Digital signatures using strong PKI encryption, buyer- and seller-side system access controls and secure Internet transmission are all available technologies to solve the critical authentication, theft and fraud protection issues. These should be table-stakes in today's commercial environment.

FW: The end of P-Cards?

Refed: **, - **, - **

From: Lynn Wheeler
Date: 10/02/2001 09:07 PM
To: Chuck@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: Re: FW: The end of P-Cards?

no, only specifically with reference to authentication, strong authentication, digital signature, ability to have strong authentication with account-based payments other than credit, implementations that have implementations for authentication.

in case you missed it, the original posting referred to a specific industry specification associated with authentication that was has been targeted at the internet specific environment that was a association specification ... not a recognized standard. furthermore there was some implication that authentication proposal could be used as an avenue to implicate some sort of service currnetly served by p-cards

here is the quote from the original posting

Anders Rundgren at 9/30/2001 10:02 AM wrote:
Having a local security device that can "connect back" to the buyer's own organization, a single virtual account and schemes like 3D Secure can eliminate the need for external user administration as well as supporting immediate updates, revocation and enablement. In addition you get full transaction record for free.

chuck wade at 10/02/2001 08:33pm wrote:
Do all of your email messages include advertisements for X9.59 and AADS? I'm having a hard time seeing the direct relevance to the thread that Anders started on the role of p-cards.

FW: The end of P-Cards?

From: Lynn Wheeler
Date: 10/02/2001 09:16 PM
To: Chuck@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: Re: FW: The end of P-Cards?

also, i think advertisements nominal apply to suggestion for vendor specific products or specifications ... i wasn't aware that mentioning ansi & iso industry, vendor neutral standards came under the heading of advertisements.

chuck wade at 10/02/2001 08:33pm wrote:
Do all of your email messages include advertisements for X9.59 and AADS? I'm having a hard time seeing the direct relevance to the thread that Anders started on the role of p-cards.

Who or what to authenticate?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 10/04/2001 07:46 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: Chuck@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Who or what to authenticate?

as mentioned before, before internet huge new fraud modes with insecure networks and ease of impersonation, 90% of fraud (and effectively still is) is insider fraud. authentication was needed for audit trail, remediation, prosecution, recovery, deterrence, etc. Some amount of the current internet focus on authentication is possible to get the internet financial state of the art up to possibly 1960 level (eliminating most outsider attacks) and then can get back to addressing the real threats involving insiders (note that there is some overlap involving authentication technology for both outsider elimination and audit trails for prosecution of insiders).

assuming that authentication can be used to eliminate outsider issues and get back to the 1960 & 1970 state of the art of addressing the real issues of insider fraud ... then you are back to audit trails for prosecution, deterrence, recovery, etc. and then possibly progressing into rules for prevention. The 1960s had checks with signing limits ... i.e. written on the face of all the checks was the maximum amount that the check could be written for. Then there are multiple signer checks ... where multiple (different) signatures could allow checks to be written for larger values. There were some mid-90s proposals for implementing 1960s level technology of insider fraud control using attribute certificates (i.e. PKI attribute certificates that had imbedded verbiage that tried to simulate check signature signing limits, aka there were some suggestions from the PKI community about regressing at least 30 years in risk & fraud control). The 1970 & 1980 electronic era was fraud and risk control with things like p-cards which not only could implement the individual transaction limits (like the check signing limits) but also real-time aggregation limits, potentially velocity limits, and misc. other rules (i.e. 1970 fraud issues where somebody wrote 200 "$5000-limit" checks in order to get $1m).

As what is at risk increases, the fraud controls tend to start involving multiple checks & balances ... i.e. like increase levels &/or number of people needed for signing. The fraud prevention scenarios also get more complex ... more & more complex infrastructure attempting to identify and/or deal with collusion. For instance, a standard corporate rule where multiple signers are involved is that vacations and leaves have to be staggered ... some number of stories where corporate risk management involves five different departments & individuals ... and one of the individuals involved in collusion goes on vacation ... and their substitute recognizes something is not quite right and the whole thing starts to unravel.

In scenarios involving serious amounts of money, for the most part the assumption is that the correct person is performing their duties and authentication can be an audit trail issue for prosecution and a deterrence because of the threat of prosecution and recovery. then there is all sorts of audit tools that look for patterns of insider-fraud as well as fraud involving complex collusion.

Anders Rundgren on 10/03/2001 10:09 PM wrote:
Chuck,

I will try to make a short comment on this.

The concept of "authorization" on a purchase order in the e-business world is today essentially non-existent. It is either "genuine", "fake", "unknown", or "damaged". But let us not get hung on that as there are legal aspects that require other definitions.

In the future I assume that purchase orders will be digitally signed. This is "authorization" according to current PKI "theology". And may even be valid as a proof in court in some countries.

Who or what to authenticate? (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 10/04/2001 01:53 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: Chuck@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Who or what to authenticate? (addenda)

... bascially what is the business goal? ... 1st make sure that the person is who they claim to be and potentially member of the insider group permitted to do certion things ... and then 2nd provide audit trail for prosecution and recovery.

as audit trail analysis of kinds of fraud got more complex, there has been some migration from detection to prevention .... i.e. up-front rules that enforce transaction rules ... possibly heuristically based on past fraud scenerios. As a result authorization becomes more complex than simple binary yes/no in an isolated context ... real-time information about all transactions and the patterns of transactions (kinds, sequences, combinations, etc), up until that point may be used as well as things like real-time transaction value aggregation or value aggregation per unit time.

A simple example is some of the (non-real-time) credit card fraud detections ... where people get calls about certain kinds of transactions or combination of transactions (hoping to not have to wait until the statement shows up to recognize fraud, while this is a good example that some number of people can relate to ... it is poor from the standpoint that it is a mix of nsiders, outsiders, non-authenticated transactions, and counterfeit).

I'm somewhat wondering about doing an authentication, authorization, accounting glossary & taxonomy similar to the payment, financial, x9f, ecurity, internet, etc, glossary & taxonomies i have on my web site (one of our hobbies is knowledge structuring, in a past life we worked on structuring of medical knowledge with NIH's UMLS):
https://www.garlic.com/~lynn/index.html#glossary

reasonable base could be the IETF AAA series of RFCs:

2903 E
  Generic AAA Architecture, Gommans L., Gross G., Spence D., Vollbrecht
J., deLaat C., 2000/08/30 (26pp) (.txt=60627)
2904
AAA Authorization Framework, Calhoun P., Farrell S., Gommans L., Gross
G., Holdrege M., Spence D., Vollbrecht J., deBruijn B., deLaat C.,
2000/08/30 (35pp) (.txt=78098)
2905
AAA Authorization Application Examples, Calhoun P., Farrell S.,
  Gommans L., Gross G., Holdrege M., Spence D., Vollbrecht J., deBruijn
B., deLaat C., 2000/08/30 (53pp) (.txt=118645)
2906
AAA Authorization Requirements, Calhoun P., Farrell S., Gommans L.,
  Gross G., Holdrege M., Spence D., Vollbrecht J., deBruijn B., deLaat
C., 2000/08/30 (23pp) (.txt=48618)

also 2977, 2989, & 3127

recent authentication thread which also includes instructions on accessing RFCs grouped by terms & categories;
https://www.garlic.com/~lynn/2001k.html#59

AGAINST ID CARDS

Refed: **, - **, - **

From: Lynn Wheeler
Date: 10/05/2001 10:39 AM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: cryptography@xxxxxxxx, dcsb@xxxxxxxx,
owner-cryptography@xxxxxxxx
Subject: Re: AGAINST ID CARDS

actually it really isn't even necessary to store most of that information in the chip ... because having it generally available that anybody can access does represent a privacy invasion and has lots of information that is potentially useful in identity theft. the approach can be somewhat analogous to the EU proposal that name information be removed from credit/debit cards.

large percentage of scenarios where something is done involving electronics with drivers license, they have gone online to obtain real-time information. This is somewhat analogous about some of my related posting about identity certificates .... which are targeted at an offline, but electronic environment requiring authentication; in effect these days the intersecting domain of 1) identity, 2) electronic, and 3) offline is becoming a near zero domain. If there is real requirement for identity (rather than just authenticate), and there are electronic facilities then almost all such domains are both online as well as near-real-time data.

in some scenarios .... it might be useful if a chip authenticated one or two of the standard age thresholds with yes/no ... but giving away actual birthdate could be considered an unnecessary identity theft risk ... as well as various and sundry other pieces of information. once things are electronic (and likely online) then it should be unnecessary in most current scenarios involving non-electronic drivers licenses to have to divulge any identity information ... just provide (potentially real-time & online) authentication of some simple pieces of information ... i.e. birthdate is unnecessary privacy and identity information ... authentication of specific age threshold is sufficient.

Done correctly, such electronic cards could eliminate some existing identity invasive information with simple trusted authentication of required criteria i.e. i can proof it is my card, & the card authenticates i'm over 21, i'm licensed for specific class vehicles, etc; legal authorities can garner what ever other information they need (including all the real-time stuff they need) from their current online process.

All the really detailed identity stuff is already in the online systems (at least in the drivers license case; in part they need to combine relatively static information with various kinds of aggregated and real-time information) ... however using chip technology could be used for eliminating much of the unnecessary card-based identity invasive information.

"Arnold G. Reinhold" on 10/04/2001 04:41 PM wrote:
I too am very nervous about the prospect of national ID cards. I have an idea for a possible compromise, but I have not made up my mind on it. I'm interested in hearing other people's opinions.

The idea is a federal standard for secure drivers' licenses. These would be cards containing a chip that stores an electronically signed and time stamped data file consisting of the driver's name, date of birth, height, address, photo, and scanned signature, as well as endorsements such as truck, school bus, motorcycle and hazmat operator licenses. All this information is contained in existing drivers' licenses, but in a way that is too easy to forge.

The licenses would still be issued by the states so there would be no new bureaucracy. People who don't drive could get "proof of age" cards using the same technology. Many states now issue such cards in conventional formats for liquor purchase. There would be pressure to expand the use of these licenses to other uses. That has already happened for conventional DLs with liquor purchase and airline boarding. Some new uses might be acceptable, e.g. using the cards to contain pilot or boating licenses. Limitations on new uses could be included in the enabling legislation.

The security model of the card would be privacy oriented, i.e. limiting who could access the cards to authorized users and the owner. The integrity of the information would come from the electronic signatures. As I understand it, much of the forgery of DLs that now takes place involves unauthorized use of the equipment that produces legitimate cards. The secure DL would cut down on this because the information on the card would be signed by the operator of the equipment, making the forgery more traceable. The data would also be signed using a key that is only available at a central location and a copy of the signed info would be retained in the driver database (this information is already collected anyway). This would make it more difficult to change just the photo on the license, for example.

The main difference between a secure driver's license and a national ID is that there would be no new requirement to obtain or carry the card. One can look at it as the nose in the camel's tent or as a way to deflect pressure for more Draconian solutions.

Thoughts?

Arnold Reinhold

At 1:47 PM -0400 10/3/2001, R. A. Hettinga wrote:

>
>Washington Bulletin: National Review's Internet Update for
>October 3, 2001
>http://www.nationalreview.com
>
>AGAINST ID CARDS
>[The worse way to fight terrorism]
>
>Only a bare majority of Americans--51 percent--support the creation of a
>national identity card, according to a new poll by Fabrizio, McLaughlin
>& Associates. This is a substantial loss of support since the Pew
>Research Center found 70 percent endorsing the concept in a survey it
>conducted immediately after the September 11 attacks.
>
>Yet plenty of warning signs remain. Westerners are only demographic
>group with a majority opposing ID cards (53 percent) and senior citizens
>are the only segment with a plurality against it (47 percent).
>Republicans and men are evenly split on the issue, with Democrats and
>women likely to favor it. Most troubling, however, may be that the poll
>shows overall support jumping to 61 percent when the ID card is
>described as �a measure to combat terrorism and make the use of false
>identities more difficult.
>
>If ever the American public was primed to accept an ID card, the time is
>now. A recent Washington Post survey reports that 64 percent of
>Americans say they trust the federal government to do the right thing
>�nearly always� or �most of the time�--the highest level of trust
>recorded since 1966 and twice the level measured just a year ago. �This
>is the most collective mood we've seen in America for a long time,�
>Democratic pollster Celinda Lake told the New York Times. �And it's
>coming off one of the most individualistic eras in American history.�
>
>The Bush administration already has signaled through a spokesman that it
>does not support the idea, though several members of Congress have
>embraced it and House immigration subcommittee chairman George Gekas, a
>Pennsylvania Republican, says ID cards will definitely receive
>consideration. Oracle CEO Larry Ellison has said his company, a leader
>in databases, would donate the software to make it happen.
>
>Conservatives must oppose these internal passports with vigor. They may
>be promoted now as tools for combating terrorism, but their potential
>for abuse is enormous. How long before the federal government also
>starts tracking gun sales through them? Or auditing income-tax returns?
>And don't forget the little prop President Clinton held up during his
>health-care speech to Congress in 1993: a �health-security card� that
>would have enabled the government's takeover of a whole industry.
>
>Terrorism is obviously worth fighting, but ID cards aren't the only way
>to do it or even the best way.
>
>(Yesterday, NRO published a symposium on ID cards:
>http://www.nationalreview.com/comment/comment-symposium100201.shtml
>And one of your correspondents, in a previous life, co-authored an
>assessment of ID cards for the Cato Institute:
>http://www.cato.org/pubs/pas/pa237.html.)

AGAINST ID CARDS

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 10/07/2001 10:13 AM
To: Carl Ellison <cme@xxxxxxxx>
cc: cryptography@xxxxxxxx, dcsb@xxxxxxxx,
    Declan McCullagh <declan@xxxxxxxx>,
"Arnold G. Reinhold" <reinhold@xxxxxxxx>
Subject: Re: AGAINST ID CARDS

slight note ... id-card-scanners at airports isn't really a cost issue, it is the cost/benefit of using them. most of the airlines have put in the gate scanners that are either mag-stripe and/or bar-code readers (the overall station cost drawfs the specifics of the actual reader part of the cost). some of them have also done extensive testing of 7816 contact chip-card readers. the problem with 7816 chip-card readers in high-traffic & transit applications is that they have very poor reliability and bad failure characteristics (for instance readers can develop burs on the contacts which rips the contacts on the card ... not only does the reader fail ... but it takes some number of cards with it). europe is starting to see some conversion from contact-card infrastructure to proximity chip cards (because of the reliability issue of contact chip-card readers) ... similar to the kind you see in Wash DC (and other) metro stations (again the gate/station cost is significantly higher than the specifics of any card reader costs ... and still can be deployed in even lower-value metro uses).

some of the financial stored-value chip-card value propositions were primarily to the operators having the float (aka you paid money to the operators which they deposited in interest bearing accounts, and they then gave you a non-interest-bearing credit in your card). that restricted value proposition may be one of the reasons that they have had lower success. However, by comparison there is pretty wide deployment and use in the US of magnetic-stripe stored-value cards (filling the same market niche as the chip-card stored value cards) .... common deployment is as "gift cards" on j-hooks at check-out counters in many department, drug, convinience, etc stores.

there is the story about one of the stored-value contact card operators making a presentation at a transit meeting. They explained that they could meet the turnstyle transversel rate by having a 10 foot "tunnel" leading up to the turnstyle ... the contact card would be loaded into a RF contactless "carrier" and if the people were forced to walk slowly thru the tunnel, the transaction could just about be completed before they reached the turnstyle.

Carl Ellison at 10/07/2001 8:23 AM wrote:
So, I think we have a harder problem than we thought we did -- but I also think that the opposition does, too. Issuing national ID cards would be expensive and would meet much resistance from the US population. Installing "ID-card-scanners" would be even more expensive, perhaps enough to stop that step from happening. (Seen any Mondex card scanners lately?) Building the underlying database mechanism would be far more expensive and would meet far more resistance, but it's not until you do the second that you have any LE value or any privacy threat at all. If all you do is ask for the ID card and don't check it, you encourage stupid uses (and therefore identity theft).

Erst-Freedom: Sic Semper Political Cryptography

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 10/07/2001 08:57 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: dcsb@xxxxxxxx
Subject: Re: Erst-Freedom: Sic Semper Political Cryptography

A slight distinction ... having been involved in the original e-commerce for financial transactions deployment .... the main purpose of the encryption was to protect the CC# ... which is effectively a shared-secret. The downside of the implementation was that the protection only occured while the transaction was "in flight" (witness all the news stories about CC# harvesting and worry about resulting fraudulent transactions). It is also not a financial standard (neither ANSI or ISO). Since it is only hiding CC# while the transaction is in flight, the typical transaction also required AVS as a weak form of authentication (i.e. name & address) which then appears also on millions & millions of web installations around the world.

On the other hand, a financial industry standard, X9.59 ... does use cryptography, but not encryption. X9.59 is a standard for all account-based transactions. It does have the characteristic that it is anonymity agnostic and is actually significantly better than the current, commonly deployed implementation. Rather than using AVS for weak-authentication, it uses digital signature for strong authentication (eliminating the need for name & address as part of the financial transaction ... and the associated appearance of names and addresses at all these merchant all over the world ... at least, in so far as required by the financial transaction). Because it uses cryptography for strong authentication (but not encryption) and has business rules that the corresponding account number can only be used in authenticated transactions; the corresponding account number is no longer a shared-secret (and targets for easy harvesting & fraudulent exploits). Since the CC# no longer is a shared-secret (and AVS weak authentication with name & address is no longer needed), then it is no longer necessary to use encryption on the transaction in-flight to protect the CC#.

The current use of encryption for protecting financial transaction in flight has only covered a small portion of the vulnerability and did nothing to elimiante the requirement for AVS week authentication with name and address. It also did nothing to eliminate the vulnerability of the associated transaction information (CC#, name & address) being resident and vulnerable at millions & millions of web installations around the world.

X9.59 with cryptography for strong authentication ... but not needing encryption for hiding information ... actually significantly improves on the current situation (that does use encryption ... but leaves CC# along with AVS weak authentication name & address information vulnerable at millions of web installations around the world). X9.59 1) eliminates the CC# harvesting as an exploit, since the account number is not usable in non-strongly-authenticated transactions and 2) elminates the requirement for AVS week authentication name & address improving the anonymity of the transaction (the information not existing at all is better anonymity than the information existing in large numbers of places ... only being encrypted for fleeting moments while transaction is in flight).

The task given the X9A10 standards work group for X9.59 was to preserve the integrity of the financial infrastructure for all electronic retail payment transactions using just authentication (not just credit, not just internet, not just point-of-sale, not just debit, etc ... ALL). It turns out that at the same time, the resulting X9.59 standard was also able to significantly improve the anonymity of the transaction (by eliminating requirement for name & address as part of AVS weak authentication).

misc. references:
https://www.garlic.com/~lynn/subpubkey.html#privacy X9.59, Identity, Authentication, and Privacy
https://www.garlic.com/~lynn/subintegrity.html#fraud Risk, Fraud, Exploits
https://www.garlic.com/~lynn/subpubkey.html#sslcerts SSL Domain Name Server Certificates
https://www.garlic.com/~lynn/subpubkey.html#radius Client and Radius Authentication

random refs:
https://www.garlic.com/~lynn/aadsm2.htm#anon anonymity in current infrastructure
https://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
https://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsmore.htm#scanon Smartcard anonymity patents
https://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
https://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
https://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
https://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
https://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
https://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
https://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
https://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
https://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance -- Liberty Alliance Project
https://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public Key
https://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
https://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
https://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2000g.html#49 Use of SET?
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001e.html#23 Pre ARPAnet email?
https://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001k.html#58 I-net banking security
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security

"R. A. Hettinga" at 10/07/2001 01:48 AM wrote:
Financial applications are both necessary and sufficient for strong cryptography to become ubiquitous. Anyone who has bought something on the net is most likely using 128-bit keys, beyond the reach of even national technical means, and they use those keys for even the most mundane of transactions, usually without even knowing what they've done.

XML vs. EDI
From: Lynn Wheeler Date: 10/11/2001 10:45 AM To: ekobor@xxxxxxxx cc: Chuck@xxxxxxxx, internet-payments@xxxxxxxx Subject: Re: XML vs. EDI
note that there are two separate issues ... one is the transport layer and the other is the end-point processing. Note that EDI flows over 822 (now 2822) email ... which has a nominal restriction of 78bytes (exclusive of cr/lf character). email has evolved things like uuencode/uudecode to deal with the 822/2822 email record restriction.

for rfc pointer references see
https://www.garlic.com/~lynn/rfcietff.htm

Emery Kobor on 10/10/2001 07:50:32 PM wrote:
Chuck,

In a previous discussion thread, the issue of ACH addenda record size came up, and you noted:

"ACH addenda records are of a fixed size, essentially card image records, as in 80 bytes! However, you can have up to 999 of them. This works (mostly) for EDI, but it's still not enough for XML."

How do EDI and XML compare, byte for byte, and what adjustments might have to be made for "financial XML" to replace "financial EDI?"

Regards,
Emery Kobor

Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/02/2001 04:21 PM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: Rubber hose attack
slight clarification .... while consumers don't directly pay the transaction fees ... whatever fees that the merchants directly pay ... show up in prices that come out of consumers pocket-book ... which they do pay ... as well as various & sundry fees that consumers pay to their issuing bank as part of various credit related fees & charges.

parts of the issue has always been would the procedures to lower fraud, cost more than the fraud they were limiting. Two things have been happening ... the cost of technology has in general been coming down rapdly ... both the cost of technology needed to limit fraud as well as the cost of technology for various kinds of fraud & counterfeiting (which tends to increase the amount of fraud).

misc threads on the subject
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm6.htm#terror14 [FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)
https://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
https://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
https://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay7.htm#fakeid Fake IDs swamp police
https://www.garlic.com/~lynn/2000f.html#64 Cryptogram Newsletter is off the wall?
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001j.html#9 E-commerce security????

credit has enjoyed quite a bit of market penetration in terms of internet transactions ... in part because it was relatively simple to adopt the existing MOTO-model to the internet
https://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/2001i.html#52 loosely-coupled, sysplex, cluster, supercomputer & electronic commerce

however, x9.59 which had a requirement to preserve the integrity of the financial infrastructure for all electronic retail payment transactions in all environments with only authentication ... also opens up other payment methods to the internet (as well as general ability to reduce fraud)
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm NACHA AADS results!!
https://www.garlic.com/~lynn/x959.html#aads

with regard to to rubber hose attack ... there is an issue of ROI (assuming a rubber hose attack has some rational financial motivation as opposed to something akin to random violence) ... i.e. effort to mount the attack vis-a-vis reward in return. The discussion of stealing a web merchant credit card master file may have a relatively modest investment but result in several hundred thousand account numbers for which fraudulent transactions can be executed against. The claim is that ROI for rubber hose attacks would preclude majority of rational financial motivation ... aka they're would be other attacks with signficiant better ROI. While rubber hose attacks might never totally disappear ... the amount of fraud from such events will be very small.

misc. past threads in the area:
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror4 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
https://www.garlic.com/~lynn/aepay7.htm#netsecure some recent threads on netbanking & e-commerce security
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure3 financial payment standards ... finger slip
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card help online shopper to feel more secure?
https://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001k.html#55 I-net banking security
https://www.garlic.com/~lynn/2001l.html#2 Why is UNIX semi-immune to viral infection?

some more general threads:
https://www.garlic.com/~lynn/subintegrity.html#fraud
https://www.garlic.com/~lynn/subpubkey.html#privacy

Johne37179@xxxxxxxx on 11/02/2001 1:25 PM wrote:
In a message dated 11/2/01 2:03:05 PM, rick_smith writes:

> Of course. But this hasn't prevented people from acquiring and using > credit cards. More to the point, it hasn't prevented the merchants, > banks, and credit card issuers from maintaining and promoting this > imperfect system. This would suggest that the losses from fraud > (which customers don't pay, at least not here in the US) are amply > covered by the income they bring in. > > This sounds to me like a system that "works" in a practical sense.
In good times when a 5% loss factor disappeared in the profits it didn't matter. In times when every penny is being squeezed (Airlines), and fraud seems to have doubled the risk management view may have changed.
John Ellingson CEO Edentification, Inc. 608.833.6261

Rubber hose attack
From: Lynn Wheeler Date: 11/02/2001 05:07 PM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: Rubber hose attack
also a somewhat related thread regarding costs for stronger authentication technology
https://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market

Rubber hose attack
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/02/2001 07:45 PM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: Rubber hose attack
the following from a thread on some of the fees related to fraud issues at
http://lists.commerce.net/archives/internet-payments/200110/maillist.html

specifically from a thread on Visa/MasterCard Antitrust Comments.

Here's an interesting quote taken directly from Judge Barbara Nelson's decision (the full text of the decision is available at:

<http://home3.americanexpress.com/corp/doj/crt_dec_011009.pdf>):
Defendants' ability to price discriminate also illustrates their market power.

Both Visa and MasterCard charge differing interchange fees based, in part, on the degree to which a given merchant category needs to accept general purpose cards.

Transactions with catalog and Internet merchants, for example, which rely almost completely on general purpose cards, have higher interchange fees than 'brick and mortar' merchants.

Defendants rationalize this difference by pointing to increased fraud in these merchant categories, but this explanation is belied by the fact that the Internet merchant, not Visa/MasterCard or their member banks, bears virtually all the risk of loss from fraudulent transactions.

Even today, Amazon's fraud rate is lower than mail-order companies, yet it is charged (indirectly, through the merchant discount) the same interchange fee as these mail order companies.

The reality is that Visa and MasterCard are able to charge substantially different prices for those hundreds of thousands of merchants who must take credit cards at any price because their customers insist on using those cards.

Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/03/2001 09:51 AM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: Rubber hose attack
i believe i said that ROI represented the total cost of the program to eliminate some fraud compared to the total amount of fraud. in the credit card scenerio it isn't enuf to know the cost per event. assuming that adding chips to those payment cards is a solution. in there US there are something less than a billion new cards sent out each year ... and adding a chip could cost on the order of $25 each. Just for the chips (ignoring for the moment the issue of reader provisioning) ... that cost might be somewhere in the $15b to $20b per annum range. There would have to be a huge number of $3500 per fraud events eliminated by a comprehensive chip program to justify it.

so as referenced in the previous postings .... advances in technology can reduce the cost of dealing with fraud (in the chip card case ... it would be nice to reduce it from $20b/annum to maybe under $1b/annum; say a combination of significantly reduced chip costs as well as the number of new sent out each year) while at the same time increasing the amount of fraud (criminals find it easier to counterfiet existing cards increasing the amount of traud that happens).

However, generically (except for some specific exceptions), the majority of fraud has tended to be insider fraud. Just improving things with strong authentication &/or identification doesn't directly address insider fraud, significant audit, command & control, and compensating procedures are needed to be in place to address significant amounts of insider fraud (who, effectively by definition, have already been authenticated and identified).

JohnE37179@xxxxxxxx on 11/02/2001 08:26 pm wrote
Again, this is only a very small part of the problem. The Inspector General's office reports that the average identity fraud in the Social Security Administration costs over $100,000. Texas Medicaid loses approximately 25% of its $4 billion budget to fraud. The ABA reports that the average cost of each credit card fraud for the issuer exceeds $3500. Each incident of identity fraud in recruiting costs DOD over $500,000.

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/03/2001 01:36 PM To: Ed Gerck <egerck@xxxxxxxx> cc: cryptography@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
I think that particular subject was discussed in some detail in the recent thread in the internet-payments archive that I previously referenced
http://lists.commerce.net/archives/internet-payments/200110/maillist.html

frequently established infrastructures may develop characteristics that are resisted to change. A slightly related thread ran in comp.arch regarding amd & hammer chip
https://www.garlic.com/~lynn/2001l.html#56

in any case, regardless of what other market forces that may come into play ... it still seemed worthwhile to do a little back-of-envelope swag on some fraud mediation cost/benefit ratios.

on 11/03/2001 11:51 am wrote:
Lynn, I guess we both know that this is the wrong business model.

The dirty little secret of the credit card industry is that they are very happy with 10% of credit card fraud over the Internet and other channels. In fact, if they would reduce fraud to zero today, their revenue would decrease as well as their profits. So, there is really no incentive to reduce fraud. On the contrary, keeping the status quo is just fine.

This is so because of insurance -- up to a certain level, which is well within the operational boundaries of course, a fraudulent transaction does not go unpaid through VISA, American Express or Mastercard servers. The transaction is fully paid, with its insurance cost paid by the merchant and, ultimately, by the customer.

Thus, the credit card industry has successfully turned fraud into a sale. This is the same attitude reported to me by a car manufacturer representative when I was talking to him about simple techniques to reduce car theft -- to which he said: "A car stolen is a car sold." In fact, a car stolen will need replacement that will be provided by insurance or by the customer working again to buy another car. While the stolen car continues to generate revenue for the manufacturer in service and parts.

Whenever we see continued fraud, we must be certain: the defrauded is profiting from it. Because no company will accept a continued loss without doing anything to reduce it. Arguments such as " we don't want to reduce the fraud level because it would cost less to reduce the fraud than the fraud costs" are just a marketing way to say that a fraud has become a sale. Because fraud is an hemorrage that adds up, while efforts to fix it -- if done correctly -- are mostly an up front cost that is incurred only once. So, to accept fraud debits is to accept that there is also a credit that continuously compensates the debit. Which credit ultimately flows from the customer -- just like in car theft.

What is to blame? Not only the myopic ethics behind this attitude but also that security school of thought most notably represented by Bruce Schneier which focus on risk, surveillance and insurance as the solution to security problems. There is no consideration of what trust is or means (), no consideration that the insurance model of security cannot scale and cannot be ethically justifiable. "A fraud is a sale" is the only outcome possible from using such security school of thought.

Cheers,

Ed Gerck

() BTW, I read some comments on trust in this tread and I must say that unless the concept of trust in communication systems is well-defined, it does not make sense to apply it. The definition that I use is that "trust is that which is essential to a communication channel but cannot be transferred through that same channel." This definition allows one use Shannon's communication theory formalism and define trust without any reference to emotions, feelings or other hard to define concepts.

Rubber hose attack
From: Lynn Wheeler Date: 11/03/2001 02:18 PM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: Rubber hose attack
what i was talking about are fully loaded costs for delivering a financial smartcard .... including hardware costs, processing, personalization, application loading, application life-cycle management, administrative, etc ... aka total infrastructure costs for such a program. frequently the hardware component of some data processing operations is one of the least significant. also there can be significant variation in chip prices based on things like chip integrity and resistance to compromise (many chips can be little better than magstrips from the stand-point of being able to duplicate and/or counterfeit).

jone37179@xxxxxxxx at 11/03/2001 2:00 pm wrote
The ratios I gave you are net. Chip costs in qualtity are under a dollar. In modest quantity (100s) up to $3.

John

3D Secure Vulnerabilities?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/04/2001 03:02 PM To: chris cook <cojock@xxxxxxxx> cc: internet-payments@xxxxxxxx, phil.griffin@xxxxxxxx Subject: Re: 3D Secure Vulnerabilities?
as several times before ... X9A10 standards working group was given the requirement to preserve the integrity of the financial infrastructure for all electronic retail payment transactions using only authentication. The resulting X9.59 is extremely light-weight ... can be completely carried in the existing x9.15/iso8583 financial network implementations for all payment cards ... and only requires authentication; not needing encryptiong at all.

having been involved in some of the original client/server payment implementation (now commonly referred to as e-commerce) .... it used session encryption to effectively prevent outside eves-dropping. At that point, one the next largest exposures were the account-numbers at the merchant site. SET had extremely huge & complex software & crypto burden that effectively provided no significant added value over what we currently had deployed and also didn't address that major exposure of the account numbers at the merchant site. There were also some misc. nigling details about production operation environment ... i managed to get some early minor changes in SET based on our production operation experience of the still existing web-based payment operations (aka electronic commerce).

Now, one of the things that x9.59 does do ... besides KISS, light-weight, all account-based transactions, etc ... was that as part of preserving the integrity of the financial infrastructure ........ it ALSO DID address the account-number exposure at the merchant sites (aka actually addresses one of the next major exposure not addressed by the currently widely deployed & used infrastructure).

chris cook on 11/4/2001 12:27 PM wrote:
Seems to me as an outsider looking in that weak (ie strong as possible without getting into huge expense) encryption plus strong authentication ain't such a bad thing for retail transactions.

Todd Boyle played a few riffs on the geo location theme in the decentralisation list (albeit mainly in the context of routing), and I am working with someone based in the area of satellite comms who has a very solid proposal for geo-based authentication (on top of PIN's etc)coupled to

reasonable strength encryption.

Basis is to tie in geographical/GPS/mobile location into authentication.

Probably not new, but the people I am working with have a powerful low cost

implementation which doesn't look too foolish to me ;-)

Chris Cook

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 09:44 AM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
slight aside, in beginning security basics end-to-end typically means that a authorization or service message requiest ..... originates with the requester and has been secured with authentication and/or encryption of the requester and travels end-to-end from the requester to the service entity ... which first validates the authorization/service request (based on the end-to-end authentication and/or encryption from the requester) and then returns an authorization or some other indication that the service is performed.

most beginning security basics teach that if authorization and/or service request does not have end-to-end security and/or integrity then the design is fundamentally flawed and opportunities for fraud is created. An example is that in SET, the card-holder/consumer's authentication information was stripped off at some random internet gateway and a flag inserted in an otherwise normal iso 8583 financial transaction message claiming that digital signature authentication had been performed. A year or so after SET pilots were in operation, somebody from VISA gave a presentation at some ISO meeting in europe detailing the percentage of iso 8583 messages where the "authenticated" flag had been turned on by some entity (and for which the consumer's issuing bank was now suppose to base various business processes and decisions) and they could positively show that no internet payment and/or any other form of digital signature authentication was involved (aka no end-to-end entegrity and/or security).

in the account-based financial transaction ... the requestor is the card-holder/consumer and the authorization or service entity is the card-holder's financial institution.

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 09:44 AM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
slight aside, in beginning security basics end-to-end typically means that a authorization or service message requiest ..... originates with the requester and has been secured with authentication and/or encryption of the requester and travels end-to-end from the requester to the service entity ... which first validates the authorization/service request (based on the end-to-end authentication and/or encryption from the requester) and then returns an authorization or some other indication that the service is performed.

most beginning security basics teach that if authorization and/or service request does not have end-to-end security and/or integrity then the design is fundamentally flawed and opportunities for fraud is created. An example is that in SET, the card-holder/consumer's authentication information was stripped off at some random internet gateway and a flag inserted in an otherwise normal iso 8583 financial transaction message claiming that digital signature authentication had been performed. A year or so after SET pilots were in operation, somebody from VISA gave a presentation at some ISO meeting in europe detailing the percentage of iso 8583 messages where the "authenticated" flag had been turned on by some entity (and for which the consumer's issuing bank was now suppose to base various business processes and decisions) and they could positively show that no internet payment and/or any other form of digital signature authentication was involved (aka no end-to-end entegrity and/or security).

in the account-based financial transaction ... the requestor is the card-holder/consumer and the authorization or service entity is the card-holder's financial institution.

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 10:20 AM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
not completely. except for some of the "know your customer rules" .... a financial institution doesn't have to identify you ... they only have to authenticate that you are the person authorized to transact with the account; aka 1) I come in and open a brand-new account and deposit a whole lot of money. 2) they give me a card with possibly PIN which is the only way that is enabled for authorized transactions. They may also record some number of shared-secrets as a fall-back position (some of the shared-secrets may involve identity information ... but that is more of a memory mnemonic, i know people that register almost random shared-secrets that have no relationship to their identity). No identity is involved. Governments may require identity for other reasons ... but it is possible to establish that it is the entity authorized to make transactions w/o requiring any identification (using purely authentication).

That is not to say that there are various kinds of fraud involving things like identity theft ... but it is possible to authenticate transactions w/o requiring identity.

There are some other issues with some infrastructures involving trusted third parties (TTPs).

I've gone into some length with regard to the discussion of TTPs and domain name web server certificates ... aka
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

where, in effect because of concerns over the integrity of the domain name infrastructure, digital certificates have been introduced. Note however, TTPs normally are not the recognized authoritative entity with regard to domain names .... TTPs just "certify" that they've checked with the authoritative entity with regard to whatever they are certifying when they manufactur the digital certificate.

Now, who is the authoritative entity for domain name information that TTPs check with when they are manufacturing a domain name web server certificate? It is the domain name infrastructure. As a result of integrity concenrs there are also integrity concerns with regard to the domain name infrastructure from TTPs (because they effectively rely on the same authoritative agencies that people are concerned about with regard to normal operation). Now the interesting part is that there are proposals that would fix the integrity problems of the authoritative domain name agency ... the domain name infrastructure .... however, if those proposals were implemented, it would also correct integrity concerns regarding the domain name infrastructure for the rest of the world ... elminating the desire they have to have domain name web server certificates as a means of compensating for the integrity issues with the domain name infrastructure (which is also the authoritative agency for domain names that the TTPs check with in order to certify domain names in manufactured certificates).

johnE37179@xxxxxxxx on 11/05/2001 10:01 AM wrote:
I think you have nailed it on the head. When authentication is viewed as the "first link" in the chain instead of identification. The problem with all authentication technologies in use today from biometrics to PKI to digital certs, all finesse the identification process and push it off to some "trusted" third party...all without clearly defining what that third party must bring to the table.

John

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 11:08 AM To: Rick Smith at Secure Computing <rick_smith@xxxxxxxx> cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, JohnE37179@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
the whole point of having manufactured certificates was to have access to some certified authentication information when it wasn't possible to contact the authoritative agency directly, primarily because you were offline. Some financial institutions did work on relying-party-only certificates ... i.e. certificates that they gave their customers that could only be used in transactions with that specific financial institution.

The process went something like:

1) public key registered in an account-record along with the certifying information (this actually applies not just to relying-party-only certificates but effectively almost all TTPs alos

2) a subset of the information from the account-record organized into some "signed", secure manufactured credential/certificate

3) a copy of the manufactured credential/certificate returned to the individual

4) individual creates transaction, signs it, appends credential, sends it off to the institutions

5) institution checks the transaction and reads the corresponding account recard

6) at this point the institution has the original of the information in the credential (and it is near real-time ... as compared to the stale copy that has been manufactured into the credential at some time in the past) ... so it is trivial to show that the credential was redundant, superfluous, and unnecessary.

7) the credential might have some meaning if there was any reason for parties that might observe the transaction in-transit to check the credential ... but it is also trivial to show that having various intermediaries looking at the credential while the transaction is in-flight is also redundant and superfluous.

So, lets apply to something like enterprise access control (instead of financial institution).

steps 1-4 are the same ... except the account record ... instead of being a financial account record is a enterprise access control/authorization employee record with near real-time information

5) let say this is radius ... which represents possibly 99.99999 percent of the client-related authentication events that occur in the world today .... radius is now sitting there with both the near real-time master of the information from the radius account record and the stale credential.

6) the near-real-time master not only is the authoritative, real-time master for the authentication information ... but also for all the near real-time authorization & privileges information. If there is both sitting there to be used ... use the near-real time master of the information or the stale, outdated copy?? ... well in this case, it is also pretty clear that the credential is redundant, superfluous and unnecessary.

7) so what random intermediaries that don't have online access to the authoritative master information might want to exercise their idle curiosity as to looking at various subset, stale information carried in a credential manufactured at some time in the past? .... or are there offline operations which are so low-value that 1) they are so constructed and in the part of the world w/o online access and 2) not worth the cost of knowing the current information rather than some stale, possibly, outdated information

Rick Smith on 11/05/2001 10:35 AM wrote:
Perhaps this is why I'm expecting PKI to flourish primarily within enterprises that run their own CAs as opposed to third parties, at least in the near term.

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 11:36 AM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
but in the financial case ... you don't have to identify them (aka their DNA) ... you just match them and the account. absolutely no identity needed. If i deposit a large sum of money and want to be the only person authorized to transact on the account ... there is no need to present identity cards at all (fake or otherwise). Supposedly, swiss bank accounts have worked that way in the past .... totally authenticated transactions, absolutely no identity. There are misc. other issue related to govs. wanting valid identities involved ... but they are extraneous to the issue of authenticating that the entity attempting to transact on the account is actually the entity authorized to transact on the account. There can be a extremely high level of confidence in an authentication system as to the entity attepting a transaction is the entity authorized to do a transaction and absolutely no identity information need to be involved. Identity information may come into play with regard to financial accounts .... but they can be totally extraneous to authenticating valid transactions.

In fact, one of the issues with regard to relying-party-only certificates (mentioned in previous post) was 1) institutions not wanting to take 3rd party liability and 2) all identity information was totally eliminated from the certificate ... leaving just the account number. This was specifically because it was an invasion of privacy that extraneous parties (like merchants) that the transaction might pass thru (and its end-to-end route) might examine the information; besides the identity information being totally extraneous and superfluous. That is a separate issue from also being able to show that just attaching such a credential was unnecessary, superfluous, redundant and extraneous (futhermore a credential that doesn't exist is even more private than a credential that has had all the interesting information removed).

JohnE37179@xxxxxxxx on 11/05/2001 11:15 AM wrote:
The real trick is identifying the person the first time. The person is a stranger and the person trying to identify them couldn't tell a fake ID from a real one.

John

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 01:12 PM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
That is specifically the point .... Bill Gates doesn't have to proove that he is Bill Gates to open an account. Bill Gates can open an account w/o prooving who he is. The financial institution just needs some reliable mechanism that the entity that opened the account and is authorized to transact against against the account is the person that is doing the transactions.

There is nothing required in authentication protocols that financial institutions use names as the authentication mechanism. A financial institution just needs some reliable authentication procedure possibly some part of traditional 3-factor authentication (#1 something you have, #2, something you know, and #3 something you are) to reliably do transactions. ATM debit tends to work that way, the debit card is something you have and the PIN is something you know. This all works with absolutely no requirement that I proove that I'm anybody. I don't have to proove that I'm either Bill Gates or that I'm Lynn Wheeler. I don't have to claim that I'm any person ... I just have to authenticated (possibly using some combination of 3-factor authentication) that I'm the entity that is authorized to transact against that account.

A financial institution could institute an "identity" related authentication mechanism .... aka I claim that I'm lynn wheeler, I proove that I'm lynn wheeler, and then the financial institution checks which accounts is lynn wheeler authorized to transact (aka just prooving identity doesn't establish that I can do a valid transaction against every account at the financial institution .... the financial institution then has to have a identity-based authentication based mechanism for doing transactions (and associating the result of identity proof with specific accounts). However, a financial institution can also have a non-identity based authentication mechanism ... similar to the existing debit card operation involving part of a 3-factor authentication operation .... aka 1) something you have and 2) something you know. It is also possible to have a 3-factor authentication operation ... aka 1) something you have, 2) something you know, and 3) something you are ... w/o the subject of a person's name ever appearing. And in fact, it is possible to have a 3-factor authentication infrastructure wheter both the #2 something you know and #3 something you are not having to ever be divulged (i.e. protocols where you can proove that you know something ... w/o the entity you prooving it to knowing what it is you know) .... aka, non-shared-secret implementations.

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 01:21 PM To: Rick Smith at Secure Computing <rick_smith@xxxxxxxx> cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, JohnE37179@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
note that "mother's maiden name" is a shared-secret #2 something you know out of 3-factor authentication. You are asked for it at the time you open the account. Note however, it is acutally, in no way an identity requirement. It is purely a human factors issue because people can have a really difficult time remembering shared-secrets (and a person isn't likely to forget their mother's maiden names). However, I know some number of people that supply somewhat random words for the "mother's maiden name" shared-secret registration and they treat it somewhat like traditional guidelines for secure passwords; 1) they are not easy to guess and 2) and for each security "domain" you use a different shared-secret (aka for instance you don't use the same moterh's maiden name with your bank and you ISP).

However, "mother's madien name" shared-secret authentication can be done with totally random words/values (and be as far from identity related as possible).

Rick Smight on 11/05/2001 1:03 PM:
When a piece of personal information like "mother's maiden name" is used for authentication, I tend to refer to it as a 'cultural secret.' Such information isn't secret in any strict sense, it's usually shared among members of a cultural group like a family, and it's hard to change. This makes it rather unreliable for use in authentication, since it can be guessed or intercepted and then replayed. In the 'e-mail to Mom' case, Mom can use a lot more information to authenticate me than Amazon can, but it reduces to the same case when we start to identify just which bits of information we plan to use.

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 01:44 PM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
I believe that I referenced that way back in my original posting to this thread .... that technology advances have made easier to counterfeit some existing mechanisms. There was also references to various press releases regarding problems with such things and various proposals.

If the authentication mechanism of entities authorized to perform a transaction ... if I have to claim to be a specific person, then proove that I'm that specific person ... and then the institution checks what things is that specific person authorized to do. Now they've tried names ... aka I can cliam to be lynn wheeler, then proove that I'm lynn wheeler. and then the institution checks on what is lynn wheeler authorized to do.

One of the problems they've found is that there are a large number of Lynn Wheelers .... if all was necessary was that I proove that I'm any Lynn Wheeler; then the problem hasn't been solved. So there still needs to be some specific way of prooving that I'm an entity that is authorized to perform a specific transaction. It is typically some combination of 3-factor authentication: #1 something you have, #2 something you know and #3 something you are.

One of the problems with some number of the current supposedly identification mechanisms is that they really are only something you know authentication .... i.e. you provide a name.

Now, things get a little more complex when you ask institutions to loan you money (or open a credit card account) ... they need some confidence that you are going to make good on the load/obligation. One way is that they send the gov. after you if you don't pay. That is a separate issue from authenticating whether you are the person that opened the account and are the authorized person to do transactions on the account. If I give the bank a bunch of money and they just need to know/authenticate that I'm the person that gave them the money .... is quite different from the issue of sending the gov. after me because of some problem or another.

JohnE37179@xxxxxxxx on 11/5/2001 1:25 PM wrote:
Again, you fudge the issue by blithely referring to "reliable mechanism." As was proven by a Brooklyn busboy earlier this year, anyone can easily bypass those "reliable mechanisms."

John

when a fraud is a sale, Re: Rubber hose attack
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler Date: 11/05/2001 03:06 PM To: JohnE37179@xxxxxxxx cc: cryptography@xxxxxxxx, egerck@xxxxxxxx, Jason.Gruber@xxxxxxxx, rick_smith@xxxxxxxx, vertigo@xxxxxxxx Subject: Re: when a fraud is a sale, Re: Rubber hose attack
the domains can be somewhat treated as prevention and deterrance/recovery.

If I can show that only the entity authorized to perform a task has been appropriately authenticated (possibly with some portion of 3-factor authentication) then I don't need identity.

I need identity for things like deterrance & recovery.

I may be able to authenticate a bank employee to know that they are a valid bank employee w/o having to know their identity. However, if there is not a system in place to prevent un-authorized and/or fraudulent transactions by bank employees (i.e. insider fraud) I may want to have identity audit trails for every transactions. Then in post mortem, the fraudulent transactions can be located and the associated individual identified which promotes some probability of recovery. Also awareness of audit trails and probability of recovery can somewhat act as deterrance.

There was large social infrastructure providing healt care to several million clients. From various sources they knew within a couple percent the size of the client population. However, they also had on their books registration for four times that number of clients (i.e. the average client was registered on the avg. four different times). What they wanted was a means of only registering a client once and always having an audit trail of provided services. They actually didn't really care who the client was (since names & address really didn't mean a whole lot).

So they created a picture card program. You needed to register to get a card and you needed the card to get services. The card effectively had an account number and a picture. When you presented a card for services, your face had to match the picture on the card (i.e. it was your card and not somebody elses ... they still didn't care who you were). When you registered for a card, a face match was made to see if you had already registered. They didn't really care who you were ... they just cared that you never got more than one card.

Basically the gov. unit had rules that everybody could get "x" amount of services (effectively for free). If you got more services for free than what the rules said, then it was fraud (the golden rule). They were interested in pevention (not deterance and recovery) ... and so didn't really care about identification ... just authentication & authorization.

Now, when you can't structure the system for prevention ... that is when you have to start worrying about identification as part of audit & recovery programs. However, even in credit card systems where person can register for a card account (basically a form of loan) and run up a large number of bills and then skip .... you can still separate the infrastructure into that portion dealing with prevention ... which only requires authentication and authorization (the actual individual charges) and that portion dealing with recovery (you skip paying the bills and somebody has to hunt you down). Even when there are multiple business operations involving some of the same business features, you don't have to apply recovery strategries (i.e. identification) in parts of the infrastructure where there is prevention and only authentication and authorization is required.

JohnE37179@xxxxxxxx at 11/05/2001 1:23 PM wrote:
Your assumption about authentication still fudges the real issue. You start out, a priori, assuming valid authentication, which is not a safe assumption. That is demonstrated thousands of times daily. In most cases the stakes are small, but there are enough 100 million dollar cases to raise the concerns. Your dismissal of linking people to transactions and records is precisely what has been required by HIPAA in healthcare. Why do you suppose it is practical there and not in financial transactions?

John

AADS Postings and Posting Index,
next, previous - home