Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home



IP: Re: Why we don't use digital cash
Sender and receiver non-repudiation
Sender and receiver non-repudiation
Electronic Checks
(certificate-less) digital signatures can secure ATM card payments on the internet
merchant web server security
Payment Processing Seminars
Payment Processing Seminars
Payment Processing Seminars
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
Did Encryption Empower These Terrorists?
The end of P-Cards?
The end of P-Cards?
The end of P-Cards?

IP: Re: Why we don't use digital cash

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/20/2001 08:02:39 AM
To: Steve Schear <schear@xxxxxxxx>
cc: "R. A. Hettinga" <rah@xxxxxxxx>, farber@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>, dcsb@xxxxxxxx
Subject: Re: IP: Re: Why we don't use digital cash
european electronic purse or stored value was a response to high cost & availability of telco in europe (i.e. the cost of the chip to the infrastructure was less than the cost of having the overall infrastructure being online). US did see the mondex trial in manhatten and various others ... but none of them "succesful".

I believe that at one point various electronic-purse equation/incentive was heavily biased towards the "float" available to the operators ... i.e. from the time that value was loaded into the electronic purse until value was eventually redeposited by a merchant or other entity. (possibly as much as 70-80% of cash flow to the electronic purse providers was in the form of float). various european govs at one point had made statements to the effect that this "float" incentive would be allowed as a mechanism for subsidising the introduction of the service .... but within a couple years, the operators would be required to start crediting the "float" to consumers accounts (i.e. the unspect value in their electronic purses). There is tremendous incentive for offering "stored-value" & "pre-paid" infrastructures because of the significant cash-flow in the form of "float" that is available to the operators.

in the us, with the online cost/availability .... the equivalent stored value was done with a "authentication" magstripe card to online accounts (i.e. seen today mostly as "gift cards" in the checkout lines at walmart, sears, penneys, nordstrom, blockbuster, etc, the gas/oil prepaid cards, etc (i.e. the trade-off was offline chip transaction cost against online magstrip transaction cost ... in the us, the online magstrip transaction was overall cheaper to the infrastructure).

in the x9.59 financial standard scenerio .... the issue for (online) stored value, debit, credit, atm, etc .... isn't the use of a chip for offline electronic purse but improvement in the integrity of the authentication operation (in part because of declining chip prices for an authentication-only chip compared to authentication magstripe in online transactions). furthermore, with the migration to economic online access starting to become available world-wide .... the european/us difference to deliverying stored-value (offline versis online) in the 90s is disappearing. the authentication-only chip also represents added value in the non-face-to-face online transactions that are typically conducted on the internet.

random refs: with regard x9.59
http://www.garlic.com/~lynn/

Steve Schear <schear@xxxxxxxx>@xxxxxxxx on 06/17/2001 10:26:22 PM wrote:
At 09:36 PM 6/17/2001 -0400, R. A. Hettinga wrote:
>
>I've gotten several comments about bearer transactions and the law
>lately, from both sides of the spectrum. The first kind is from
>people who say they're afraid that nation states are going to
>prohibit bearer transactions no matter how cheap they are. The
>second, from anarchists like Steve Shear, below, say that they can
>only be used for illegal transactions and that illegal transactions
>are, actually, the highest and best use of internet bearer financial
>cryptography. They're both wrong. And for exactly the same reason:
>internet bearer transactions should be considerably cheaper than the
>way we do things now...

Where did I say illegal transactions. And I'm not an anarchist, I just think nation states need a bit more competition in most every arena and that competition won't be willingly offered by nation states. I simply stated that cost reductions alone won't easily drive new markets.

I doubt that Eurodollars/bonds would have ever developed if the offering institutions simply said transaction costs are zero but taxes still apply. Lower transaction costs in conjunction with new abilities can be a winning hand, but without those abilities they're a losing proposition except in mature markets and when offered by well established players, not new ventures who's safety and survival may be questionable.

For most parties, transaction costs represent only a small fraction of overall business costs. Look at what happened to CyberCash. They thought cheaper transactions would make them rich. It didn't, mainly because the cost of CC transactions for online merchants was only a small part of their cost to get and stay online (marketing costs were much larger).

Despite your enthusiasm, a new financial instrument from a new venture cannot be based on cost reductions. The risks, real or imagined, are too great. Now, offer them something key that the competition can't or won't and you've got a shot at getting some action from those who can now see your risk vs. possible reward as acceptable. Forget Joe six-pack. Forget online merchants (initially).

steve


Sender and receiver non-repudiation

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/03/2001 08:55:36 AM
To: Panayiotis Kotzanikolaou <pkotzani@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: Sender and receiver non-repudiation
there is even simpler "misappropriation" ... that of virus on the machine ... how do you really know what your computer is doing.

with paper signatures .... it is somewhat more clear-cut that the person signing a document ... is actually looking at the document they are signing. With digital signatures it becomes murkier ... how does somebody know that what they are looking at is the same thing that the computer is calculating a digital signature for.

in retail situations, the burdon of proof is typically with the institutions to disproove any claims of forged signature.

some of the draft digital signature laws (associated with certificates and certification authorities) started out trying to move that burden of proof to the consumer (i.e. most of the laws don't so much talk about non-repudiation per se ... they talk about disputes and who has the burden of proof and the standards for burden of proof). Some of these somewhat implied that a certificate was sufficient proof ... somewhat ignoring there could be thousands of foibles that might result in a digital signature not being what the key owner expected.

business issues typically are associated with amount of risk ... aka how hard is it to defeat or compromise some system, how hard is it to show intent, etc.

random refs:
http://www.garlic.com/~lynn/2001g.html#25 Root Certificates
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/ansiepay.htm#anxclean Misc 8583 mapping cleanup
http://www.garlic.com/~lynn/2000f.html#64 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?

Sender and receiver non-repudiation

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/03/2001 02:09 PM
To: Eugene Leitl <Eugene.Leitl@xxxxxxxx>
cc: Panayiotis Kotzanikolaou <pkotzani@xxxxxxxx>,
    <cryptography@xxxxxxxx>
Subject: Re: Sender and receiver non-repudiation
all true

it was part of the original point ... which was that much of the writing about security in conjunction with digital signatures .... all have to do with the responsibilities of certification authorities.

However, it is possible to have a totally insecure infrastructure with the best certification authority along with their best policies and practices ... and still have a situation like the "Emperor's new clothes".

It is further possible to have a terrible secure infrastructure with secure chip-card, secure public/private keys, secure display, secure processes, along with trusted digital signatures ... and have absolutely no certificates.

In lots of cases, you can treat certification authorities and certificates as totally orthogonal to the issues involved in trusting digital signatures.

some random refs:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#privacy
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
http://www.garlic.com/~lynn/subtopic.html#radius

Eugene.leitl@xxxxxxxx on 7/3/2001 9:55:38 wrote:
On Tue, 3 Jul 2001 Lynn.Wheeler@xxxxxxxx wrote:

> there is even simpler "misappropriation" ... that of virus on the machine
> ... how do you really know what your computer is doing.
The more control you have over your machine, and the environment, the more security you have. By hiding sensitive tasks into armored compartments you can push this way further, making it sufficiently secure for all practical purposes.

> with paper signatures .... it is somewhat more clear-cut that the person
> signing a document ... is actually looking at the document they are
> signing. With digital signatures it becomes murkier ... how does somebody


But you are looking at a representation of a document, as rendered in the frame buffer. If you're worried about your machine being compromised, either use armored crypto hardware protected by clean protocols/interfaces, or an air gap protected machine containing only the barest OS essentials and crypto binaries, only transferring _passive_ (thanks to MS, it's essentially just plain ASCII) documents via sneakernet.

For practical purposes you would use a smart card with a crypto processor on it. I personally think it would be interesting to see what can be done with polymer/OLED frame buffers printed directly on the top of a deep embedded, which does both video and crypto directly in the framebuffer compartment, and only talks via a fast packet switched network to the rest of the (wearable) computer. The less code and state is in there, the less potential for exploits.

> know that what they are looking at is the same thing that the computer is
> calculating a digital signature for.


-- Eugen Leitl http://www.lrz.de/~ui22204/
ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3


Electronic Checks

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/20/2001 02.52 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: Digital Bearer Settlement List <dbs@xxxxxxxx>,
dcsb@xxxxxxxx
Subject: Re: Electronic Checks
rah@xxxxxxxx on 7/20/2001 10:40:30 AM wrote:
stephen.middlebrook@xxxxxxxx on 7/20/2001 13.10.31 wrote:
>
> That said, the Treasury Dept. working with the Financial Service
> Technology Consortium (FSTC) developed and piloted what we call an
> "echeck" which was in fact an electronic check -- not an ACH --
> governed by check law but always digital and sent over the
> internet. Echecks were used to pay a small number of defense
> contractors.


note that there were two different banks clearing e-checks in the FSTC pilot ... one transferred the money thru the ACH network and the other thru the debit network. The internal economics to the two clearing banks was significantly different because of the float issue.

there is the x9.59 financial stnndard (aka e-check was a specification, not being the work of an accredited standards organization)

http://www.garlic.com/~lynn/

several of the people that worked on the FSTC e-check activity also participated in X9A10 (the standards work group responsible for X9.59).

also, NACHA has done a digital signature pilot (with debit network; with digital signatures; and w/o digital certificates) and now various (debit network) parties are looking at production deployment (draft submitted under somebody else's name):

http://www.garlic.com/~lynn/nacharfi.htm

we had also done the draft for what was then being called "SWIFT2" for digital signature transactions.

one of the major reasons at the time for FSML specification was that (at the time) XML lacked a set of deterministic encoding rules. Much of the digital signature stuff has been specified with ASN.1 encoding rules since they are deterministic. The issue for FSTC was that while the data elements were defined for generating digital signature and for verifying digital signature, they did not specify how the data elements were transmitted. That resulted in the relying party potentially having to regenerate the digitally signed message from individual components that might have been transmitted in a different form than their signing form. As a result, the relying party had to use the same deterministic encoding rules for recreating the digitally signed message as that used by the originator of the digitally signed message. At the time, XML didn't have such a set of deterministic encoding rules.

Something similar is allowed for in X9.59, defining the bits that are signed and verified but not necessarily the bits that are transmitted. That allows for transmitting the individual fields as components of existing financial transaction messages. Such a mapping between X9.59 and ISO8583 is given at:

http://www.garlic.com/~lynn/8583flow.htm

Showing a possible mapping between x9.59 data elements and ISO8583 payment network elements (note "additional" field has already been accepted in the latest ISO8583 standard to carry the additional data elements outlined in the above reference).

A similar mapping has been done for the ACH network (as well as something for the SWIFT network).

The biggest functional difference between e-check and the X9.59 standard (other than one being a specification and the other a standard) ... is that the e-check definition specifically specified one or more signatures (to support the analog of check co-signing) while the number of signatures aren't part of the x9.59 definition (is left as an implementation specific issue, the objective that x9.59 could be used for all account-based electronic payments).

random refs:


http://www.garlic.com/~lynn/aadsm5.htm#xmlvch implementations of "XML Voucher: Generic Voucher Language" ?
http://www.garlic.com/~lynn/aadsm5.htm#epaym "e-payments" email discussion list is now "Internet-payments"
http://www.garlic.com/~lynn/aadsmore.htm#nacha NACHA digital signature pilot
http://www.garlic.com/~lynn/aadsmore.htm#x959demo AADS X9.59 demos at BAI (annual world-wide retail banking) show in miami next week
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 XML, encryption and certificates
http://www.garlic.com/~lynn/aepay6.htm#vouc implementations of "XML Voucher: Generic Voucher Language" ?
http://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set (authentication is the key)
http://www.garlic.com/~lynn/ansiepay.htm#aadsach NACHA to Test ATM Card Payments for Consumer Internet Purchases
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/ansiepay.htm#x959demo X9.59/AADS demos operational
http://www.garlic.com/~lynn/99.html#136 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#157 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#171 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo standards at BAI (world-wide retail banking) show
http://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000f.html#22 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#25 Why trust root CAs ?

(certificate-less) digital signatures can secure ATM card payments on the internet

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/04/2001 08:51:41 AM
To: cryptography@xxxxxxxx
Subject: (certificate-less) digital signatures can secure ATM card payments on the internet
press release ("digital signatures can secure ATM card payments on the Internet")


http://www.nacha.org/news/news/pressreleases/2001/PR072301/pr072301.htm

results

http://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

the report

http://web.archive.org/web/20020106102303/http://internetcouncil.nacha.org/Projects/ISAP_Results/ISAPresultsDocument-Final-2.PDF

includes the following from the above ...

The "real-world" viability of the proposed ANSI X9.59 standard concept for electronic payments using public/private key pairs, which is also known as Account Authority Digital Signature (AADS), was validated by the ISAP Pilot results. These results demonstrate the feasibility of using PKI without digital certificates, thereby minimizing infrastructure requirements and costs for utilizing the ISAP process.

============================

The rfi for the above:

http://www.garlic.com/~lynn/nacharfi.htm

additional information on x9.59 and AADS

http://www.garlic.com/~lynn

nacha web site

http://www.nacha.org/

nacha organization

Welcome to NACHA

Welcome to the web site of NACHA - The Electronic Payments Association. Here you will find the latest information on the innovative and dynamic world of electronic payments.

Electronic payments of all kinds are used frequently by people, companies, and government agencies as a safe, reliable and convenient way to conduct business. Direct Deposit is used for payroll, travel and expense reimbursements, annuities and pensions, dividends, and government payments such as Social Security and Veterans benefits. Other types of electronic payments are frequently used for bill payments, retail purchases, Internet purchases, corporate payments and treasury management, and for the provision of food stamps and other government cash assistance.

NACHA is a not-for-profit trade association that develops operating rules and business practices for the Automated Clearing House (ACH) Network and for other areas of electronic payments. NACHA activities and initiatives facilitate the adoption of electronic payments in the areas of Internet commerce, electronic bill payment and presentment (EBPP), financial electronic data interchange (EDI), international payments, electronic checks, electronic benefits transfer (EBT) and student lending. We also promote the use of electronic payment products and services, such as Direct Deposit and Direct Payment.

NACHA represents more than 12,000 financial institutions through our network of regional ACH associations. We have over 600 members in our seven industry councils and corporate Affiliate Membership program.

I hope you will find this web site to be a valuable resource. Please come again!

merchant web server security

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/13/2001 07:28 AM
To: dcsb@xxxxxxxx
Subject: merchant web server security
from a discussion in comp.security.misc. ....

net banking, is it safe??? ... power to the consumer
net banking, is it safe??? ... security proportional to risk


http://www.garlic.com/~lynn/2001h.html#58
http://www.garlic.com/~lynn/2001h.html#61

however, the merchant systems are attractive targets since 1) current credit card transactions are not authenticated and 2) merchant-related card business processes involve merchants maintaining file on previous transactions (aka the credit card numbers).

as a result havesting the merchant credit card file ... enables a large number of fraudulent (unauthenticated) transactions across possibly hundreds of thousands of credit card accounts.

aka the previous transaction information ... account number, et. al are essentiall shared-secret ... since it is sufficient for generating a fraudulent transaction.

going to authenticated transactions ... aka x9.59 and the nacha trials ... eliminates the harvesting of the credit card file as a meaningful exploit since the information contained in the file is no longer sufficient for generating a fraudulent transaction.

x9.59 and the nacha work didn't directly improve the security of the merchant web sites ... it just eliminated the major attack point at merchant web sites as a meaningful fraudulent activity (such files could still be harvesting, it just wouldn't result in fraud).

random refs:
http://www.garlic.com/~lynn/aadsm6.htm#aadsatm
http://www.garlic.com/~lynn/2001h.html#37
http://www.garlic.com/~lynn/2001h.html#53
http://www.garlic.com/~lynn/subtopic.html#privacy

it also has an interesting personal side-benfit ... effectively empowering the person. significant amount of the current fraud revolves around the degree that merchant sites protects the consumer's data. a consumer doing large number of transactions at a large number of different sites is dependant on each & every one of those sites never, ever, making a security mistake.

going to authenticated transactions ... moves the point of attack from the merchant to the person (besides eliminating the fraudulent multiplier benefit of one event harvesting sufficient information capable of generating tens of thousands of fraudulent transactions) ... the person now has some control over the possible points of attacks (and is not dependent on a continuing bases the security of all the merchants that they have ever done business with).

now lets look at it from a slightly different perspective.

nominally the amount of security is typically proportional to what is at risk.

let say a web merchant offers a $5 item (that costs $3 wholesale) and sells 100,000 of them thru credit card purchases.

that is $500,000 gross revenue, or $200,000 left to cover operating, mailing, security, salaries, profit, etc.

so, in theory, what is at "risk" should be in the $10,000 to $500,000 range (depending on whether only transactions in a certain window are at risk or aggregate of all transactions are at risk). so, in theory, some amount of the $200,000 should go to providing security proportional to risk.

however, the merchant credit card transaction file is effectively at risk proportional to the credit limit of all the customers ... not proportional to what it is that they bought from the merchant ... and effectively doesn't have a narrow time window (other than say the card expiration date). Taking a nominal credit limit of $500, then what is at risk is now in the $50,000,000 range (not the $10k to $500k range).

Let say there are something like 10,000,000 such merchants world-wide with similar profile ... ignoring for the moment, the fact that they have to have credit card file security that protects from both outsider and insider exploits ... each and every one of those merchants now needs security that is proportional to a $50,000,000 risk rather than a couple hundred thousand dollar risk (at most) ... i.e. what is at risk is possibly one hundred to one thousand times as large as what the individual merchants directly are dealing with. Any sort of failure at any one of those 10,000,000 merchants results in a $50,000,000 exposure.

One could make the claim that each individual merchant doesn't have the revenue and/or the risk profile to cover the actual total risk that their credit card file represents and/or fund the necessary associated security that is proportional to the actual risk.

One of the things that I worked on was resource management algorithms that are proportional to the resource. Resource management algorithms that incurred an expense much larger than the value of the resource they managed weren't likely to survive. It was necessary to have a management algorithm that was proportional to the value.

Applying the analogy to merchant credit card risk ... the risk that they are securing needs to be proportional to their business operations (i.e. revenue and profit) and not proportional to something that they have no control over (like the aggregate of all the credit limits for all the customers that they happen to deal with).

random refs:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#privacy
http://www.garlic.com/~lynn/subtopic.html#fraud

Payment Processing Seminars

Refed: **, - **, - **
From: Lynn Wheeler
Date: 9/4/2001 04:18:14 PM
To: Richard Dumm <rdd4@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: Re: Payment Processing Seminars
BAI also puts on a number of seminars in all aspects of banking

http://www.bai.org/events/index.html

at this years BAI retail delivery there will be session(s) on the NACHA AADS results

http://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

original draft proposal for above

http://www.garlic.com/~lynn/nacharfi.htm

.... BAI has a number of conferences as well as technical seminars at the conferences as well as a number of other technical seminar events
Transaction Processing 2002

The most comprehensive program for payments, operations and technology professionals. This multi-faceted event, includes more than 30 sessions from six tracks on key issues and the largest exhibit hall of its kind featuring over 150 exhibiting companies.


The retail delivery blurb:
Retail Delivery 2001

Industry's largest retail financial services conference, bringing together nearly 10,000 financial services professionals from over 75 countries. Features innovators who share their philosophy on executing strategic plans and achieving market leadership.


another BAI reference


http://www.bai.org/education/index.html

Richard Dumm on 09/04/2001 01:21:30 PM wrote:
I was curious if anyone knew of any "Payment Processing" schools or
seminars dedicated to learning the detailed in's/out's of credit card
and ACH electronic processing.

I am not interested in Payment Processing software, but training on
banking industry payment processing processes.

Thanks,
Richard


Payment Processing Seminars

From: Lynn Wheeler
Date: 09/04/2001 04:41:05 PM
To: Richard Dumm <rdd4@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: Re: Payment Processing Seminars
also ... may be of some interest ... i have a payment glossary & taxonomy

http://www.garlic.com/~lynn/payment.htm

and a much larger (that includes the payment entries) financial glossary & taxonomy

http://www.garlic.com/~lynn/financial.htm

also of some interesting in the other glossaries:

http://www.garlic.com/~lynn/index.html#glossary

Payment Processing Seminars

Refed: **, - **, - **
From: Lynn Wheeler
Date: 09/04/2001 05:03:51 PM
To: Richard Dumm <rdd4@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject:  Re: Payment Processing Seminars
misc. stuff from BAI web education search
https://secure.bai.org/profiting/registration_form.html
https://secure.bai.org/ecp2001/reg.htlm
http://www.bai.org/ecommerce/insights.html
https://secure.bai.org/downloads/products/bench95/orderform.html
https://secure.bai.org/benchcp98/order_form.html
https://secure.bai.org/aggregation/reg.html
https://secure.bai.org/b2b/reg.html
http://www.bai.org/ecp2001/dayone.html
http://www.bai.org//retaildelivery/workshops.html
http://www.bai.org/sitemap.html

[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/17/2001 08:21 PM
To: jim_windle@xxxxxxxx
cc: cryptography@xxxxxxxx,
"Hadmut Danisch" <hadmut@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
we were somewhat involved in the implementation of support of commerce server and hiding account numbers using SSL encryption (probably one of the most wide-spread use of the technology in the world today).

random refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

The problems, of course are 1) account numbers are essentially shared-secrets, 2) SSL only provides for protection for numbers in flight, 3) the numbers at rest remain a major exploit (as per press stories regarding copying of account number master files at web servers) ... aka the use of SSL/ecryption only addressed a small portion of the problem. The web server account number master file also typically represents a risk that is significantly greater than what typical merchant otherwise has at risk ... making it difficult to support a solution where the level of security/protection is proportional to the risk
http://www.garlic.com/~lynn/aepay7.htm#netbank2

note that the X9.59 financial standard for all account-based payments (by the x9a10 financial standards body) ... achieves the goal of protecting both data at rest as well as the data in flight by defining transactions as being authenticated with digital signatures (and that account numbers used for x9.59 related transactions can not be used in unauthenticated transactions). Furhtermore, since account numbers are no longer shared-secrets ... it isn't necessary to "hide" the transaction (with encryption) in order to protect the account number. There may be other reasons for using SSL encryption for data in flight ... but with x9.59, the primary current use of SSL (protecting the account number in flight as part of electronic commerce) is no longer necessary (and x9.59 is a much more comprehensive, full spectrum solution ... because it not only addresses the issue of data "in flight" ... but also problems with the data/numbers "at rest").

numerous x9.59 references
http://www.garlic.com/~lynn/

some specific x9.59 references
http://www.garlic.com/~lynn/subtopic.html#privacy

some other discussions related to SSL domain name certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

digital commerce trivia question
http://www.garlic.com/~lynn/aadsmore.htm#dctriv

"Jim Windle" on 09/17/2001 10:11 AM wrote:
On Mon, 17 Sep 2001 11:50:13   Hadmut Danisch wrote:
>
>Depends on which kind of logic you apply.
>
>Technical logic: Yes, you're right.
>
>Policital logic: No, you're wrong.
>
>The reason is, that air planes, phones, hotels, cars, etc.
>are used by common people - those who elect politicians -
>and therefore can't be bad by definition. Policital logic:
>What is used by most people who elected me, can't be wrong.
>Which politician would dare to ban hotels?
>
>In contrast to that, cryptography isn't commonly used or
>understood. From a public point of view, cryptography is
>something exotic, used by spys and secret agents, hackers,
>terrorists, who need to keep their business secret. And even
>worse: It's new (at least its civil use with internet). All
>other things exist for decades and have become part of
>normal life. Cryptography doesn't.
As Perry points out in his comment here and as I pointed out in my follow up posts, crypto is not so exotic as it may first appear. Not only is it installed in browsers and used to buy books and whatever else people buy on the internet while protecting their financial information; it plays and essentianl role in the financial markets. While this application may be largely invisible to most people it is of tremendous importance. You point out that crypto is a "martial" technology, to some extend this is true, but it is increasing used in commercial applications. This uses are enabling some of the most vibrant sectors of the economy that contribute greatly to growth in GNP and productivity. Radio and airplanes were primarrily "martial" technologies in their early years, and yet have changed the face of civilian life in subsequent years. Suppose non-military use of those technologies had been banned at the beginning or World War I? In the same way the "martial" users of crypto were insensitive to cost and user friendliness and were the early adapters. As crypto becomes easier to use and more available it will be used to facilitate the move of a large percentage of commercial transactions to the internet to reduce costs, and uses not even imagined now will likely be found and become ubiquitious.


[FYI] Did Encryption Empower These Terrorists?

From: Lynn Wheeler
Date: 09/18/2001 06:34 PM
To: jim_windle@xxxxxxxx
cc: cryptography@xxxxxxxx, "Hadmut Danisch" <hadmut@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
you may then also find "The Thread Between Risk Manaement and Information Security" interesting

http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn/aepay3.htm#riskaads

somewhat more from the risk manager's perspective ... than either straight cryptography or computer security.

jim_windle@xxxxxxxx on 09/18/2001 12:08 PM wrote:
Lynn,

Thanks for the references. I looked at an online trading system about a year ago, more from a strategic planning perspective really (this is not my normal role either). What I found intriguing was the interaction between protocols and market structure, particularly in the fixed income and foreign exchange markets. This market are far larger than than the equity markets with individual trades often well into the hundreds of millions of dollars (your point abouth security commensuarate with the risk is well taken), but unlike the equity or futures markets they are not open outcry markets. The structure of these markets is rather complicated with a variety of institutions playing several different, fairly well defined roles. Depending upon the protocols chosen the resulting electronic "exchange" canbenefit one or more classes of market participants at the expense of others. Hence the plethora of different system trying to establish themselves, at one point there were more than three dozen different systems with a vide variety of protocols and security features depending on whose interests and what information they were trying to protect. As you point out the issues go well beyond the problems of a merchant protecting a customers credit card number when that customer buys a book online. Anyway thanks for the references.

Jim Windle


[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/24/2001 10:31 AM
To: Ben Laurie <ben@xxxxxxxx>
cc: cryptography@xxxxxxxx,
Hadmut Danisch <hadmut@xxxxxxxx>, jim_windle@xxxxxxxx
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
there are all sorts of shortcomings in this world. you find a "merchant" that buys a computer, installs some webserver software and puts it up and the web and expects that to handle everything.

there are sometimes prevalent things like that in the world; it would be nice if people would choose a random 16-character value for every PIN/password they need, that every PIN/password they have is different, that every password/PIN changes at least monthly, and that every person could easily remember one or two hundred 16-character random values that change monthly, and no PIN/password is ever re-used.
misc. pin/password ref:
http://www.garlic.com/~lynn/2001d.html#52

security proportional to risk:
http://www.garlic.com/~lynn/aepay7.htm#netbank2

misc. information security & risk management:
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn/aepay3.htm#riskaads

misc. web refs:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#privacy

http://www.garlic.com/~lynn/2001j.html#5
part of above posting ....
when we were working on the credit card transaction stuff (now frequently referred to as electronic commerce):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we tried to get various security measures specified:

... didn't happen, oh well.


Ben Laurie at 09/24/2001 02:34 AM wrote:
lynn.wheeler@xxxxxxxx wrote:


> The problems, of course are 1) account numbers are essentially > shared-secrets, 2) SSL only provides for protection for numbers in flight, 3) the > numbers at rest remain a major exploit (as per press stories regarding > copying of account number master files at web servers) ... aka the use of > SSL/ecryption only addressed a small portion of the problem. The web server > account number master file also typicall represents a risk that is > significantly greater than what typical merchant otherwise has at risk ... > making it difficult to support a solution where the level of > security/protection is proportional to the risk


This is simply bad design - there should be no "account number master file" on the web server!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff


[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/24/2001 11:11 AM
To: Ben Laurie <ben@xxxxxxxx>
cc: cryptography@xxxxxxxx,
    Hadmut Danisch <hadmut@xxxxxxxx>, jim_windle@xxxxxxxx
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
of course, the other problem is that a substantial part is the "customer at risk" (not just merchant at risk exposure as the result of any merchant implementation short comings) .... and there is currently no obvious way that a customer can determine what, if any, security standards a merchant might have implemented.

as mentioned in the various previous references ... what is at risk ... effectively proportional to the aggregate of the account credit limits ... for all accounts that happened to have been stored in any account master file ... is significantly larger than any particular merchant may have directly at risk because of a security breach. in the security proportional to risk theory .... the entity that has the risk should have control over the security measures, those security measures should be proportional to what they have at risk, and the cost of those security measures should also be proportional to the risk.

A complex, multi-system internet web implementation may represent a significantly greater cost than the direct busines value a merchant may be doing on the internet (not to mention the cost of the care and feeding of such an implementation). I would claim that any impression that such an implementation is required is proof that what is at risk (value represented by the account master file) is not directly related to what any merchant might have at risk with putting up a merchant web server. Furthermore, I would claim that it would be possible to find account master files (regardless of the volume of a merchant's internet business) that represents a risk level higher than the merchant direct risk ... and therefor there will always be merchants (at all business size segments) that find it difficult to provide security proportional to that risk.

Ben Laurie at 09/24/2001 02:34 AM wrote:
This is simply bad design - there should be no "account number master file" on the web server!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff


[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/24/2001 01:52 PM
To: Ben Laurie <ben@xxxxxxxx>
cc: cryptography@xxxxxxxx,
    Hadmut Danisch <hadmut@xxxxxxxx>, jim_windle@xxxxxxxx
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
If it was so easy ... it wouldn't be a problem. An objective of the original e-commerce deployments was that the account number file not be co-located on the webserver. Since a large number of subsequent deployments have co-located on the webserver or on some equally accessable location would tend to indicate that it isn't as easy as it might first appear.

One might suspect that the definition of "easy" is rather relative ... and also there may be some questions regarding what aspect of the issues does "easy" apply to (internet easy, server easy, webserver easy, technology easy, programming easy, business process easy, process easy, etc).

I would claim that having it become so prevalent after the initial subsequent deployments would imply that there are at least some issues involved that make it much more than a simple, straight-forward, brain-dead matter (if it was trivially obvious for everybody in world, then there is some rational that nobody would have done in such a way that creates such security & risk issues).

Ben Laurie at 09/24/2001 01:32 PM wrote:
lynn.wheeler@xxxxxxxx wrote:


> > there are all sorts of shortcomings in this world. you find a "merchant" > that buys a computer, installs some webserver software and puts it up and > the web and expects that to handle everything.
Fine, but that was not the point you claimed to be making. You said:


> The web server > account number master file also typicall represents a risk that is > significantly greater than what typical merchant otherwise has at risk ... > making it difficult to support a solution where the level of > security/protection is proportional to the risk
but that is simply not true - it is very easy to eliminate this particular piece of crap design.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff


[FYI] Did Encryption Empower These Terrorists?

From: Lynn Wheeler
Date: 09/24/2001 01:52 PM
To: Ben Laurie <ben@xxxxxxxx>
cc: cryptography@xxxxxxxx,
Hadmut Danisch <hadmut@xxxxxxxx>, jim_windle@xxxxxxxx
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
re: easy;

almost 30 years ago, we shot a scripting type virus on the internal network and then laid down some "easy" rules that would preclude any new scripting virus &/or trojan horses.

if it really was as trivial and easy as we thot 30 years ago ... by definition, the majority of the recent rash of exploits, viruses, et al ... would never have happened. Since the expolits did happen (and are continuing) ... then there must be issues involved that are not be quite as easy as we thot 30 years ago.

i spent some amount of my young years around various types of farm equipment and thot it was easy living thru it (although when I was around 10, i let lady-fingers explode in my hand & when I was older ... worked re-bar w/o gloves). Later, along came HEW and set out guidelines that a lot of the stuff I grew up working around was dangerous equipment and in various cases needed substantial modifications (what I thot was easy at the time, subsequently was judged very dangerous).

[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/25/2001 09:29 AM
To: "Enzo Michelangeli" <em@xxxxxxxx>
cc: "Ben Laurie" <ben@xxxxxxxx>, cryptography@xxxxxxxx,
"Bill Frantz" <frantz@xxxxxxxx>, "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
note that financial standard body
http://www.x9.org/

in the financial standards body has passed X9.59 standard for all electronic account-based payments that uses digital signature for authentication (and has business rule that account numbers used in authenticated transactions are not valid in non-authenticated transactions). As a result, account numbers are eliminated as a point of attack. In the past, while there may have been protocols that encrypted transactions and/or authenticated transactions, the business rules for the account numbers didn't change, so the account number master file remained a point of exploit. The ISO 8583 field for carrying the X9.59 data has also passed at the international level (ISO8583 is the international standard for the backbone ATM, debit, and credit networks).

misc. refs to x9.59
http://www.garlic.com/~lynn/

X9.59 is applicable to internet, point-of-sale, debit, credit, etc ... aka ALL account-based transactions. Work had started on X9.59 in the '96 time-frame in the X9A10 work group which was given the charter of a standard that preserved the integrity of the financial infrastructure using only authentication that was applicable to all account-based transactions. Many of the issues was coming up with a light-weight, strongly authenticated transactions that would have minimal impact on the existing infrastructure and could be applied to all transactions. Much of the X9.59 standardization activity was going on at the same time as some of the corporate specification work (aka there is a difference between a corporate specification and a financial body standard)

Having been involved in the original e-commerce deployments
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and in some of the original deployments of some of the corporate specification implementations ... convenience wasn't the only downside issue. One of the issues was what incremental advantage did they provide? i.e. both provided encryption of transaction in flight, but neither provided any protection against harvesting of account numbers at rest.

In the credit case, it isn't even necessary to change the business rules, putting the burden of proof on the consumer ... since much of the problem has been using harvested credit card numbers in fraudulent unauthenticated transactions. Since X9.59 defines only authenticated transactions ... it is no longer possible to harvest x9.59 credit card numbers and use them in fraudulent unauthenticated transactions (which has been major fraud and exploit up until now).

NACHA/Internet council has finished such a trial with debit and some members are progressing with production deployment. X9.59 would eliminate many of the differences between credit and debit ... making both the same strongly authenticated transaction.

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

misc set refs:
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#pkimort2 problem with the death of X.509 PKI
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#sslset1 "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/aepay4.htm#visaset Visa Delicately Gives Hook to SET Standard
http://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard
http://www.garlic.com/~lynn/aepay4.htm#3dssl VISA 3D-SSL
http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
http://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
http://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#40 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#42 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#43 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001h.html#72 ummmmm

"Enzo Michelangeli" on 9/25/2001 07:45 AM wrote:
"Steven M. Bellovin" on Sep 25 2001 6:31 AM wrote:

>
> Actually, I believe it's by the merchants.  Internet transactions
> generally count as "card not present" transactions, which means that
> the merchants take the risk.
That's correct, and it's the main rationale behind initiatives like Visa's 3D Secure: an attempt to introduce stronger cardholder authentication, so that the liability for chargebacks may be shifted back to the issuer.

This is actually the second attempt at solving this problem: offering chargeback protection to merchants was the main attraction of SET, and merchants and their acquiring banks were also ready to pay for it. However, it was so inconvenient for the cardholders that they avoided SET-enabled e-tailers like the plague...

Enzo


[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **
From: Lynn Wheeler
Date: 09/25/2001 09:41 AM
To: Ben Laurie <ben@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
what I (attempted?) to say was that the "typical" merchant and or "typically" at merchants ... the account number file is vulnerable and frequently is also on the same system as that running the web server. The original/first implementation had the account file and the transactions performed on a separate back-end system. That original implementation didn't become the prevailing deployed operational infrastructure. It doesn't matter that the original implementation of a separate back-end system was better or worse ... it didn't prevail.

In general, the harvesting of the account number master file is a major vulnerability ... whether it is on the same system or a different system. Moving it to a different system may or may not make it less vulnerable to harvesting by internet-mounted attacks. Mostly, in the past, insider attacks have been considered 90% of the vulnerability problem (although recently internet-mounted external attacks get more of the press).

For the very first implemetation, we believed we had an implementation for back-room credit card transactions that was significantly less vulnerable to internet-mounted attacks. The point was that is not what prevailed and is not what is commoningly deployed.

ben laurie wrote:
It is easy to avoid this piece of bad design, for example by transferring asymmetrically encrypted order details to a back-end system (via email is a popular choice).

Of course, the system is still vulnerable to trojan-style attacks (in fact it seems to me that even this could be avoided with some cunning client-side work - it would even be valuable to extend, say, SSL to permit this - I wonder if it would be worth describing how this could be done?).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff


[FYI] Did Encryption Empower These Terrorists? (addenda)

Refed: **, - **, - **
From: Lynn Wheeler
Date: 09/25/2001 10:47 AM
To: "Enzo Michelangeli" <em@xxxxxxxx>
cc: "Ben Laurie" <ben@xxxxxxxx>, cryptography@xxxxxxxx,
"Bill Frantz" <frantz@xxxxxxxx>, "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists? (addenda)
using x9.59 for all account-based transactions would put debit & credit on a level playing field with regard to authenticated transactions (and promotes debit use over the internet).

besides the significant difference in merchant cost infrastructure between the two ... the other remaining difference is the significant difference with regard to consumer recourse between the two ... i.e. credit has a lot of regs that effectively allow consumer to "trust" a transaction (not only based on trust in the merchant, but also in the merchant bank and the consumer bank) ... even a merchant that the consumer has had no prior knowledge and/or dealings with. This has been touted as a significant factor on the internet with the non-face-to-face characteristic of the consumer/merchant relationship and any consumer anywhere in the world could do business with any merchant anywhere in the world, aka the credit regs with regard to consumer recourse infrastructure providing significant benefit in such an environment (with merchant, merchant bank, consumer bank all having various levels of responsibility ... even in the case of a merchant going bankrupt; a significant issue for merchant banks with regard to credit is airline tickets ... a significant fee source, but also can be a major liability if the airline goes bankrupt).

however, with regard to the internet trust issue ... the consumer e-commerce transactions don't have a random, homogeneous distribution between all consumers and all merchants ... the distribution tends to be quite skewed with possibly 20-30 locations accounting for 60-70 percent of all transactions and possibly 100 locations accounting for 90 percent of all transactions. There is much less of an "unknown" issue involving transactions with the top tier well-known merchants that everybody frequents as well as individual consumers having done multiple transactions with the same merchant(s) in the past. In this scenerio (for possibly 90 percent of internet transactions) there is much less of a difference between credit and debit with regard to the consumer not knowing and/or having no knowledge on which to base "trust" in the merchant. In the situation involving possibly 90+ percent of internet e-commerce consumer transactions the consumer would tend to have very little difference in the level of amprehension with regard to using either (x9.59) credit or (x9.59) debit for the transaction.

Credit (either x9.59 or not) would still provide a consumer perceived advantage when dealing with the vast majority of the internet merchants that account for relatively trivial percentage of all transactions (aka rather than just judging whether they trust just the merchant, they can also rely on the trust in their consumer bank as well as possibly in the associated merchant bank).

random refs:
http://www.garlic.com/~lynn/aadsm2.htm#useire2 U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...

[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date:09/26/2001 06:07 AM
To: Enzo Michelangeli <em@xxxxxxxx>
cc: Ben Laurie <ben@xxxxxxxx>, cryptography@xxxxxxxx,
    Hadmut Danisch <hadmut@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
misc discussion regarding SET NEVER intended to hide PAN from the merchant (in part because, a merchant gets dispute notification directly from the consumer's bank with the only reference being the PAN, the date, and the amount).
http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards

note that the issuing (consumer) bank and the acquiring (merchant) bank don't necessarily have the same interests. in the standard SET scenerio, the only thing that the issuing bank sees is a flag in an 8583 message saying that some internet gateway someplace may have correctly authenticated a digital signature on a SET transaction. there is no end-to-end security and/or authentication. about a year into some of the SET deployments, somebody from VISA gave a presentation at an ISO meeting in europe on the number of 8583 transactions arriving at an issuing bank with the SET signature verified flag turned on and they could proove that both the merchant, any gateway, and the acquiring bank had absolutely zero SET and/or other digital signature technology (the flag was just being set).

Part of the issue was that the size bloat of a SET transaction compared to a normal 8583 transactions could approach two orders of magnitude .... in part resulting in the gateway performing the signature authentication and then throwing away everything and just setting a flag in the 8583 message claiming that the authentication was performed.

Part of the x9.59 standard design point was to be light-weight enuf so that there could be real end-to-end security with real end-to-end authentication that actual flows with the real transaction (that was also in part derived from the requirement that x9.59 standard could be applied to all account-based transactions, regardless of internet, point-of-sale, debit, credit, existing infrastructure, new infrastructure, etc).

In the x9.59 standards scenerio, the merchant doesn't even need SSL technology (at least not for integrity/fraud reasons, some people may still prefer SSL ... but it would be a privacy issue, not a fraud & integrity issue). The merchant gets a couple more data elements which must be mapped into X9.15 (or the 8583 subset equivalent) for sending directly to their acquiring processor. The processing would be exactly the same for an internet web site as for a point-of-sale terminal. The processing would also be the same whether it was debit or credit (except for possibly X9.15/8583-subset protocol differences between their credit processor and their debit processor ... if any).

misc. past discussion regarding real end-to-end security
http://www.garlic.com/~lynn/aadsm2.htm#integrity Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#keylength On leaving the 56-bit key length limitation
http://www.garlic.com/~lynn/aadsm2.htm#keyl2 On leaving the 56-bit key length limitation
http://www.garlic.com/~lynn/aadsm2.htm#keyl3 On leaving the 56-bit key length limitation
http://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures, technology experiments, and service operations
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#privacy misc. privacy
http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
http://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on DSTU X9.59
http://www.garlic.com/~lynn/ansiepay.htm#anxclean Misc 8583 mapping cleanup
http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000.html#61 64 bit X86 ugliness (Re: Williamette trace cache (Re: First view of Willamette))
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#23 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates

discussions regarding SSL domain name certificate infrastructure:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

general discussions regarding x9.59, privacy, authentication
http://www.garlic.com/~lynn/subtopic.html#privacy

general discussions regarding client authentication
http://www.garlic.com/~lynn/subtopic.html#radius

general discussion regarding fraud & exploits
http://www.garlic.com/~lynn/subtopic.html#fraud

Enzo Michelangeli on 9/25/2001 8:56 PM wrote:
Many merchants need a unique identifier for the buyer, and their traditional processes often use the PAN (card number, for credit transactions). According to what I heard, at one point the original specs of SET were altered in order to accomodate, as an option, the visibility of the PAN to the merchant, thereby giving up the other advantage of SET besides cardholder's authentication (i.e., protection of the card number from eyes different from cardholder's or banking system's).

As Ben noted, it is not difficult to combine the following two requirements:
a) protection of PAN from any party different from cardholder or acquiring bank
b) no special software installed on cardholder's PC besides an SSL-capable browser

For example, let's suppose that the acquirer run a stateful trusted and well protected machine (gateway), and the merchant a simple secure web server whose CGI scripts can act as SSL clients. The transaction protocol could work this way:

1. At check-out time, the merchant server connects to the gateway with SSL, authenticates itself (even simple username/password is OK) and passes to the gateway the details of the transaction, minus the card number (that it doesn't have).

2. The gateway creates a record in an internal database, stores the data there, and returns a unique and unguessable handle (a random-looking string with a length of a few tens of characters).

3. The merchant server redirects the buyer's browser to the gateway, passing it the handle (e.g., appended to the URL as "get" parameter). Also this HTTP session is over SSL.

4. The gateway prompts the buyer for the card number and other personal details, in a form also containing the handle as hidden field.

5. The buyer enters the requested data, and submits. The gateway, through the handle, retrieves the transaction record, combines its data with the card number and other data entered by the buyer, processes the authorization request through the card associations' network, gets back the auth code, stores it in the database transaction record, and redirects the browser to a URL on the merchant server, again appending the record's handle as parameter.

6. The merchant server gets the handle, opens another SSL connection (also authenticated) to a URL on the gateway also passing it the handle, and gets back a receipt confirming the authorization. It then displays a "Thank you" page to the buyer's browser, and communicates all the data to the division in charge for the order's fulfillment. The End.

And lo: no fancy crypto (apart from SSL), which also helps performances; no client certificates; and no bulky wallets that someone gotta pay for (and have to be installed, and often crash Windows ;-) ). Also the merchant server just needs very simple and inexpensive SSL client software: cURL, CryptSSL+LWP, JSSE, whatever.

The only piece still missing here is the cardholder authentication: the gateway is managed by the acquiring bank, but only the issuing bank has business relationships with the cardholder, and is in the position of putting in place authentication mechanisms. That's where 3D Secure may help.

Cheers --

Enzo


[FYI] Did Encryption Empower These Terrorists?

From: Lynn Wheeler
Date: 09/26/2001 06:14 AM
To: Eric Murray <ericm@xxxxxxxx>
cc: cryptography@xxxxxxxx, Enzo Michelangeli <em@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
one slight distinction from ansi/iso standards body perspective .... SET was an industry specification not a standard ... and in fact at one point I believe there was some statement that SET was never going to be submitted for standardization consideration.

[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/27/2001 07:07 AM
To: Ray Dillinger <bear@xxxxxxxx>
cc: Ben Laurie <ben@xxxxxxxx>, cryptography@xxxxxxxx,
    Enzo Michelangeli <em@xxxxxxxx>, Hadmut Danisch <hadmut@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
note that X9.59 standards work spent quite a bit of time attempting to minimize the number of places that identity might have to occur. In general an X9.59 account number can be related to a person (i.e. possibly bank regs related to "know your customer"). It attempts to only do strong authentication with digital signature ... but leaving as few identity fingerprints as possible (at least as far as the financial transaction is concerned). Also, strongly authenticated transactions significantly reduces the possibility that fraudulent transactions have occured.

Also, since X9.59 standard was to be applicable to all account-based transactions ... it had to be agnostic with respect to identity information to cover financial transactions that didn't have the rules and regulations associated with credit ... say debit and/or even "stored value" (say a digitally signed version of those "gift cards" that are frequently found at check-out stands at places like blockbuster, sears, etc).

Ray Dillinger at 9/26/2001 10:06 AM wrote:
A few problems:
2) No provision for dispute resolution. What happens in a month and a half when george gets his credit card bill back and says "I've never been there and never done any business with this person"? The bank generates a chargeback and sends it to the merchant who, in the absence of knowledge about the buyer's identity, has no recourse. George may or may not be the person who made the transaction; but the merchant has no way to even begin to try to find out.

In general, "anonymity" and "credit" are immiscible. If you want anonymous transactions, you absolutely cannot abide by the laws that require chargebacks, merchant and/or bank liability in case of fraud (instead of consumer liability), etc. Compliance with those laws requires the merchant and banks to have the very information that anonymity prohibits them from having.

For anonymous transactions, you want something a whole lot more like cash, with the same failure modes (ie, no shift of liability in case of fraud) as cash. That requires infrastructure which will not be allowed to be built.


[FYI] Did Encryption Empower These Terrorists?

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/27/2001 07:24 AM
To: "Enzo Michelangeli" <em@xxxxxxxx>
cc: "Ray Dillinger" <bear@xxxxxxxx>, "Ben Laurie" <ben@xxxxxxxx>,
     cryptography@xxxxxxxx, "Hadmut Danisch" <hadmut@xxxxxxxx>
Subject: Re: [FYI] Did Encryption Empower These Terrorists?
I'm not sure I understand. A lot of the association credit regs have to do with establishing consumer confidence & trust when dealing with totally unknown merchants. Disputes/chargebacks can be more than "I didn't perform that transaction" (mostly because it is so easy to execute non-authenticated fraudulent transactions) ... there are a whole variety of disputes/chargebacks having to do with non-delivery &/or non-performance ... i.e. even in credit card & card holder present situations; In fact, there is the whole scenerio referenced previously where airline tickets are bought with a credit card and the airline goes bankrupt ... the acquiring bank is then liable.
http://www.garlic.com/~lynn/aadsm6.htm#terror9

even with authenticated transactions there are still some aspects of MOTO-transaction reg (mail-order, telephone-order) that could still apply ... for instance, in the case of hardgoods, your account is not to be billed until goods are actually shipped. there is still the scenerio that goods never shipped.

if disputes/chargebacks were to be totally eliminated for authenticated transactions then (x9.59) credit & debit would really be put on a totally level playing field ... also discussion
http://www.garlic.com/~lynn/aadsm6.htm#terror9

note that there are some basic security 101 principles that can be applied here ... as done by X9.59 ... whenever there isn't end-to-end continuous security & end-to-end continuous, seemliess authentication (say when it is split into multiple different operations and transactions and not a single seemless operation) then there are bound to be gaps & cracks in the security .... into which fraud can creep ....

"Enzo Michlangeli" on 9/26/2001 5:26 PM wrote:
That's 3D Secure's job (see above). Once the issuer has authenticated the cardholder, neither merchant nor acquirer can be held responsible for chargebacks: the issuer pays, and then deals with its cardholder as it deems fit. (If you want my opinion, the very reason why Visa developed 3D Secure is that they are sick of being involved in the dispute resolution process).

[FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/27/2001 01:04 PM
To: "Enzo Michelangeli" <em@xxxxxxxx>
cc: "Ray Dillinger" <bear@xxxxxxxx>, "Ben Laurie" <ben@xxxxxxxx>,
    cryptography@xxxxxxxx, "Hadmut Danisch" <hadmut@xxxxxxxx>,
jim_windle@xxxxxxxx
Subject: Re: [FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)
Basically there are chargeback rules for card holder present, card present, as well as ability to read track 1&2 (on mag. stripe). One of the issues is that even in card present scenerios with indication that trace 1&2 could be read, there are starting to be counterfeits and fraudulent transactions: http://www.garlic.com/~lynn/aepay6.htm "out of control credit card fraud"

In the X9.59 scenerio using something along the lines of an AADS card:
http://www.garlic.com/~lynn/aadsm2.htm#straw

there is plauseability that it could represent "stronger" authentication than current card present (i.e. much harder to counterfeit) even when non-face-to-face, MOTO, &/or internet transactions are involved.

However, fraudulent transactions (either in MOTO/internet scenerio or card present ... because of short-comings in strength of authentication) still doesn't account for all the reasons for charge-backs &/or disputes ... aka even given absolute perfect authentication and no (consumer) fraudulent transactions ... there are still reasons for charge-backs and/or disputes.

ref:
http://www.garlic.com/~lynn/subtopic.html#publickey

The end of P-Cards?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/30/2001 02:54 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: Re: The end of P-Cards?
having any online, ubiquitously connected system with easy rule update and change is an interesting challenge no matter who or how it is deployed (especially with strict security and audit control for what is permitted and/or changed, aka the whole objective of the system in the first place, problem is also that traditionally, 90percent of fraud has been insider fraud)

some of the larger corporations are starting to even have further deployment of p-cards with the infrastructure providing statement->edi translation that flows everything directly into the backend accounts payable system. auto-industry with possibly 60,000 suppliers is one that comes to mind.

a couple issues:

1) making it easier for the low-to-mid-range companies ... aka standard skewed scenario ... majority of the value flow thru relatively small number of operations. This is somewhat of a dichotomy between the major financial processors and possibly software vendors. The market that represents the majority of value and number of transactions would tend towards a small number of frequently roll-your-own and/or custom implementations which is possibly contrasted to web-oriented software vendors focusing on the volume (in terms of unit sales), cookie-cutter, mass-market (but possibly having lowere aggregate total number of transactions and value)

2) when p-cards are platformed on credit association infrastructures ... there is significant invention typically required regarding traditional fees (watching some of the GAO stuff on the various federal p-card awards comes to mind).

3) network that is optimized at processing thousands of 60-100byte authorizatiion transactions per second securely and in real time would be impacted by any significant increase in level-3 data. Note however, with various consolidation & outsourcing that it is approaching 90% of transactions are handled in possibly half-dozen to dozen centers ... increasing that inter-center bandwidth capacity would be relatively straight-forward (I believe that there have already been announcements about 20% of the traffic being moved off the traditional association networks to inter-center direct links).

Note that X9.59 financial standard with token that works identically the same at POS and non-face-to-face (internet, etc) could be considered even more secure and ubiquituously applicable.

Not only does not having seemless end-to-end transaction authentication in conjunction with transaction authorization an invitation for fraud ... but also making it really simple and easy for insiders to access the system and make rule changes is also an invitation to fraud. Typically, if you aren't worried about insiders and fraud/skimming/etc ... then you probably aren't good candidate for p-card rules in any case; just direct transaction presentment to backend automated accounts payable may be sufficient (x9.59 at POS and network supporting seemless, end-to-end strong transaction authentication).

misc. refs:
http://www.garlic.com/~lynn/subtopic.html#fraud Risk, Fraud, Exploits
http://www.garlic.com/~lynn/aadsm2.htm#useire2 U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aadsm4.htm#01 redundant and superfluous (addenda)
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aadsm6.htm#terror9 [FYI] Did Encryption Empower These Terrorists? (addenda)
http://www.garlic.com/~lynn/aepay3.htm#smrtcrd Smart Cards with Chips encouraged ... fyi
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
http://www.garlic.com/~lynn/ansiepay.htm#aadsach NACHA to Test ATM Card Payments for Consumer Internet Purchases
http://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???

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.

The end of P-Cards? (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/02/2001 07:43 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: Re: The end of P-Cards? (addenda)
slight clarification

1) p-cards isn't an issue of outsider fraud, it is more of an issue of insider fraud/skimming. while x9.59 strong authentication would be nice for preventing outsider fraud ... it is something that is applicable to all cards. x9.59 standard is designed to support all account-based transactions (not just credit) ... even the stored-value type account transactions (the current gift card type implmentations that can be seen at check-out counters at places like sears, walmart, blockbuster, etc). in some sense p-cards are a modern real-time version of the old fashion corporate checks with signing limits written on the face of the check (rules can be on individual transaction limits ... but also real-time velocity and/or aggregation).

2) level-3 data is only an issue for sku-level fules ...i.e. rules that regulate down to what specific merchandanise an employee can buy (i.e. stocking codes). just standard credit platform can support limit, velocity, mcc-codes (merchant cantegory codes), merchant, store, location, etc ... with just the standard data that currently flows. level-3 data is needed if employer needs to specify sku-level rules (and/or the employer needed sku-level reporting for other reasons ... see #3)

3) auto-industry example was a mechanism that provided a way of getting full transaction detail from their 60,000 some suppliers w/o having to force the little guys to support full-edi. all their suppliers needed to do was support standard credit platform ... and the processors credit backfroom processing did the translation of credit transactions into edi-format for the industry standard processing (aka suppliers supporting p-card platform was simpler than supporting full edi). It also has the advantage of working the same whether it is POS or various non-face-to-face transactions (like internet).

4) both #2 & #3 have invention issues/challenges with the standard credit fees when platformed using standard credit infrastructure.

The end of P-Cards? (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/02/2001 08:08 AM
To: internet-payments@xxxxxxxx
Subject: Re: The end of P-Cards? (addenda)
also ... p-card rule complexity isn't inherent in the back-end infrastructure. security procedures for rule changes need to be proportional to what is at risk (aka rules are in place to minimize fraud/skimming, being able to change the rules easily can increase the fules/skimming). slightly related discussion that security procedures need to be proportional to risk:
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk

i've seen references to "family" card offerings .... effectively a p-card like offering that parents can give to their kids with various simple rules that even parents can modify w/o much difficulty. It doesn't need level-3/SKU support just existing data which can give limit, velocity, MCC, merchant, regions things (both POS and non-face-to-face use). For these scenarios, the risk tends to be significantly lower than corporate risk ... so the security procedures concerning rule updates can be simpler also. The problem is similar to the corporate p-cards ... the unit "executives" wishing to have some spending control along with audit trail.

AADS Postings and Posting Index, next, previous - home