X9.59 mailing list

x959 Postings and Posting Index,
next, previous - home

8th CACR Information Security Workshop (human face of privacy)
Fake IDs swamp police
non-repudiation, was Re: crypto flaw in secure mail standards
non-repudiation, was Re: crypto flaw in secure mail standards
non-repudiation, was Re: crypto flaw in secure mail standards
non-repudiation, was Re: crypto flaw in secure mail standards
non-repudiation, was Re: crypto flaw in secure mail standards
XML digital signature authentication reference
non-repudiation, was Re: crypto flaw in secure mail standards
non-repudiation, was Re: crypto flaw in secure mail standards
Shared-Secret exploit
Nacha reports mentions X9.59 payment protocol
Visa Debit Card
Visa Debit Card
fyi ... Comments requested on ETSI Draft TR "XML format for signature policies"
net banking, is it safe?? ... power to the consumer
net banking, is it safe?? ... security proportional to risk
some recent threads on netbanking & e-commerce security
Network Identity Alliance -- Liberty Alliance Project
Another Thing to Feer: ID Theft
With security a sudden priority, 'smart card' technology gets a second look
Reports of Identity Theft Still Rising Fast
3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
financial payment standards ... finger slip
3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
Unified Modeling Language (UML) for NACHA Business Models & XML Project
X9.59 paper ... fyi

8th CACR Information Security Workshop (human face of privacy)

From: Lynn Wheeler
Date: 06/29/2001 02:22 PM
To: ansi-epay@xxxxxxxx
Subject: 8th CACR Information Security Workshop (human face of privacy)

===========================================
8th CACR Information Security Workshop
& 2nd Annual Privacy and Security Workshop:
The Human Face of Privacy Technology
November 1, 2, 2001
===========================================

This is the first announcement. Please pass this announcement to any colleagues who might be interested in attending.

For updates, including the abstracts of talks and speaker bios, workshop program, and hotel information, please see www.cacr.math.uwaterloo.ca under "Conferences". This information will also be included in the second announcement to be mailed on July 16, 2001

INTRODUCTION:

The 8th CACR Information Security Workshop: The Human Face of Privacy Technology will be held November 1 & 2, 2001, at the University of Toronto, Canada (exact location to be announced). This is the second annual conference jointly organized by the Information Privacy Commission of Ontario and the Center for Applied Cryptographic Research, University of Waterloo.

WORKSHOP THEME:

Cell phone users were recently outraged when their private conversations were streamed live over the Internet. Digital cell phone users became equally stressed when the wireless encryption standard - 802.11 they had been using to protect their conversations was cracked. Even more disconcerting, places such as Guatemala see human rights workers, using privacy technologies to protect other civil rights groups' identities and the information they report on civil rights abuses, experience daily threats of information theft as well as kidnappings.

Within the last year those involved in developing and implementing technology have experienced a growing awareness of privacy risks within those technologies and a better understanding of privacy averse environments. This awareness has brought to the fore the need to further develop and implement technologies that are privacy protective. Parallel to this, around the globe, economic crime units and law enforcement agencies, governments, businesses and lawyers wrestle with the tools to combat the international specter of cyber crime, while often sidelining key privacy issues. The exploration of privacy and security issues is fundamental to understanding how the construction and implementation of privacy policies and technologies can be improved for the real world.

This year's workshop will explore these and other privacy and security issues through a mix of traditional panel discussions and presentations as well as a Mock Cyber Crime Trial with audience participation and an interactive subject rights counter-surveillance event lead by Dr. Steve Mann, U of Toronto.

The workshop builds on the comments and suggestions provided by last year's delegates and speakers who suggested a further exploration into both leading edge privacy and security technologies and an exploration of the context that these technologies work within. As a result, the conference has been expanded to cover two days, including parallel breakout sessions. Attendee spots have been increased to 210 to meet demand and more time for discussion and networking has been set-aside in the evenings. For early registrants a conference package will be sent out before the event that includes additional material on the conference objective, speakers/organizers and a detailed backgrounder for the scheduled Mock Cyber Crime Trial that will take place.

The intended audience includes technology and security experts, CIO's, senior technology executives, cryptographers, engineers, law enforcement, academics, private sector leaders, privacy experts and students.

SPONSORS:

    Certicom Corp.
Communications Security Establishment, Canadian Federal Government
    Information & Privacy Commission, Ontario
JetNet Managed Internet Services Inc.
MITACS
Pitney Bowes

ORGANIZERS:

    Mike Gurski (Conference Chair)
Information & Privacy Commission, Ontario

Alfred Menezes
Centre for Applied Cryptographic Research (CACR), University of Waterloo

    Sherry Shannon
Centre for Applied Cryptographic Research (CACR) & SVI Consulting

SPEAKERS (partial list):

    Dave Banisar, Sr. Fellow, EPIC (Electronic Privacy Information Center)
Dr. Ann Cavoukian, Ontario Information and Privacy Commissioner
Dr. Jennifer Grannick, Clinical Director - Center for Internet &
Society, Stanford University
    Scott Hutchison, Sr. Prosecutor, Ontario Ministry of the Attorney General
Dr. Steven Mann, University of Toronto
    Mary O'Donoghue, Information & Privacy Commission, Ontario
Stephanie Perrin, Chief Privacy Officer, Zero Knowledge and
Recipient of the 2001 Electronic Frontier Foundation's Pioneer Award
Ron Ross, President, Jet Net
    Ari Schwartz. Center for Democracy and Technology
Lawrence Surtees, IDC & Network World columnist
    Kristen Tsolis, Cyber Terrorism Researcher, U.S. Navy Postgraduate School
Dr. Scott Vanstone, Founder & Chief Cryptographer, Certicom
Minky Worden, Electronic Media Director, Human Rights Watch

WORKSHOP PROGRAM:

To be included in the second announcement on July 16, 2001

REGISTRATION

There is no registration fee for guests invited by the sponsors (Certicom, Communications Security Establishment, Information & Privacy Commission, Jetnet, MITACS, and Pitney Bowes). The registration fee for other participants is as follows:

- Cdn $300 (US $150).
   - For participants affiliated with an academic institution:
Cdn $150 (US $75).

Please register as soon as possible as space is limited for this workshop; registration is on a first-come first-serve basis.

Please note that there may be an additional banquet fee of Cdn $30 (US $20) for all registrants who wish to attend the workshop banquet on November 1. Details will be included in the second announcement.

To register, complete, in full, the attached REGISTRATION FORM and return it along with your payment (if applicable) to:

Mrs. Frances Hannigan,
    C&O Dept., University of Waterloo, Waterloo,
Ontario, Canada N2L 3G1.

You may also register by email (fhannigan@xxxxxxxx) or by phone (Frances Hannigan: 519-888-4027).

ACCOMMODATIONS:

The workshop will be held at The University of Toronto, Toronto, Ontario.

Each participant will arrange their own travel and accommodation for the meeting. There are many hotels close to The University of Toronto. A list of hotels will be provided in the second announcement.

TRAVEL:

The closest airport is Lester Pearson Airport (Toronto Airport).

For further information please contact:

Mrs. Frances Hannigan
Department of Combinatorics & Optimization
University of Waterloo
      Waterloo, Ontario, Canada   N2L 3G1
e-mail:  fhannigan@xxxxxxxx
      Fax:     (519) 725-5441
Phone:   (519) 888-4027
http://www.cacr.math.uwaterloo.ca/

Fake IDs swamp police

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

From: Lynn Wheeler
Date: 07/02/2001 10:09:18 AM
To: ansi-epay@xxxxxxxx
Subject: Fake IDs swamp police

somewhat related to previous identity theft and counterfeit card postings

http://www.usatoday.com/news/nation/2001/07/02/fake-ids.htm

other refs:

https://www.garlic.com/~lynn/subpubkey.html#privacy

https://www.garlic.com/~lynn/subintegrity.html#fraud

https://www.garlic.com/~lynn/subpubkey.html#sslcerts

non-repudiation, was Re: crypto flaw in secure mail standards

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

From: Lynn Wheeler
Date: 07/07/2001 12:26:44 PM
To: Greg Broiles <gbroiles@xxxxxxxx>
cc: jamesd@xxxxxxxx, James M Galvin <galvin@xxxxxxxx>,
cryptography@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards

one of the biggest problems that has led to most of the regulations is the ease that account-number harvesting can occur and then the account number used in fraudulent, non-authenticated transactions. The SET-like protocols didn't address this issue. However, there is a huge amount of stuff going on about the need for implementing absolute perfect security at the millions of merchant sites scattered all over the world ... where there is an absolute guarantee that at each and every site, harvesting by either external agents and/or internal agents would absolutely never occur.

by contrast the X9.59 standard (US ANSI financial standards bodies and pushing forward to international ISO) does address this issue ... where it allows that the probability of absolte security and each and every web-site implemented in the world never fails and that there still won't be fraudulent transactions in association with any kind of (internal or external) account number havesting (aka charter given the X9A10 working group in the definition of X9.59 was to preserve the integrity of the financial infrastructure for all electronic retail payment transactions. The claim also is that X9.59 definition is also identity agnostic and can suppurt EU regulations/guidelines that retail transactions need to not have identity information (i.e. name information embossed on the plastic and recorded on the magstripe).

misc. ref:

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

The X9.59 standard can be obtained from the ANSI publication web site.
https://web.archive.org/web/20020214081019/http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9.59-2000

gbroils@xxxxxxxx on 7/5/2001 wrote:
Implementing non-repudiation as a countermeasure versus spurious "do not recognize" chargebacks seems to depend on all of the following:

(a) development and widespread adoption of a secure platform for key storage and Internet use, like the system "whose user interface and underlying technology is such that the signature is unlikely to be forged . ." described by James Donald above

(b) merchants forcing customers to adopt that platform and SET-like procedures in order to carry out transactions

(c) changing the Fair Credit Billing Act to make it more difficult or impossible for consumers to dispute items on their bills.

non-repudiation, was Re: crypto flaw in secure mail standards

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

From: Lynn Wheeler
Date: 07/07/2001 12:38:14 PM
To: Greg Broiles <gbroiles@xxxxxxxx>
cc: jamesd@xxxxxxxx, James M Galvin <galvin@xxxxxxxx>,
    cryptography@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards

... and the x9.59 solution was designed to be applicable to "all" account-based, electronic payments .... not just credit ... but "all".

much of the regs. are specific to credit (because of the ease that account-number harvesting can lead to fraudulent, non-authenticated transactions) ... while the x9.59 approach can not only be used to address credit but debit as well (one of the other account-based, electronic payments).

an example is the completed nacha pilot

again refs at

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

non-repudiation, was Re: crypto flaw in secure mail standards

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

From: Lynn Wheeler
Date: 07/08/2001 10:15:32 AM
To: EKR <ekr@xxxxxxxx>
cc: Greg Broiles <gbroiles@xxxxxxxx>, jamesd@xxxxxxxx,
James M Galvin <galvin@xxxxxxxx>, cryptography@xxxxxxxx,
    ansi-epay@xxxxxxxx
Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards

true ... but it wasn't standard business practice ... there were all sorts of options ... the issue was what were the standard business practices actually followed.

I believe that there is a thread from two years ago on this specific subject ... where somebody associated with SET explicitly stated that the standard business practices were not designed to preclude the merchant from having the PAN.

I can look up the discussion if you are interested.

non-repudiation, was Re: crypto flaw in secure mail standards

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

From: Lynn Wheeler
Date: 07/08/2001 10:39:32 AM
To: EKR <ekr@xxxxxxxx>
cc: Greg Broiles <gbroiles@xxxxxxxx>, jamesd@xxxxxxxx,
James M Galvin <galvin@xxxxxxxx>, cryptography@xxxxxxxx,
    ansi-epay@xxxxxxxx
Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards

specific ref.

https://www.garlic.com/~lynn/aepay3.htm#sslset1

in a thread with one of the SET people from visa ... they stated that it was not designed to prevent a valid merchant from getting the PAN ..... in fact, that there are standard credit card businness process that require the merchant to have the PAN and that the PAN was alwas returned to a valid merchant from the payment gateway. I had made the assertion that possibly the SET option could have been overriden ... which would have inhibited the ability of the merchant to perform normal credit card business processing ... and was corrected that it was always designed that the PAN be returned to a valid merchant (and not to inhibit the merchant from being able to execute standard business processes).

misc. set references from past discussions

https://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))
https://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on DSTU X9.59
https://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
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#sslset1 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aepay4.htm#visaset Visa Delicately Gives Hook to SET Standard
https://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard
https://www.garlic.com/~lynn/aepay4.htm#3dssl VISA 3D-SSL
https://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
https://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
https://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!

misc. electronic commerce discusions
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

Eric Rescorla <ekr@xxxxxxxx>@xxxxxxxx on 07/07/2001 11:54:44 AM wrote:
Lynn.Wheeler writes:
one of the biggest problems that has led to most of the regulations is the
ease that account-number harvesting can occur and then the account number
used in fraudulent, non-authenticated transactions. The SET-like protocols
didn't address this issue.

How so? In at least one mode, SET denied the merchant the PAN.

non-repudiation, was Re: crypto flaw in secure mail standards

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

From: Lynn Wheeler
Date: 07/09/2001 10:02:49 AM
To: EKR <ekr@xxxxxxxx>
cc: Greg Broiles <gbroiles@xxxxxxxx>, jamesd@xxxxxxxx,
James M Galvin <galvin@xxxxxxxx>, cryptography@xxxxxxxx,
     ansi-epay@xxxxxxxx
Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards

for a fuller discussion of SSL & SET discussion ... set x9a10 mailing list archives

http://lists.commerce.net/archives/ansi-epay/199905/maillist.html

the above has the postings in reverse cronological order.

but, basically the bottom line is that there are a number of merchant credit card business process that require the merchant to have the PAN (or merchant credit card stuff doesn't work).

specific posting (from somebody at visa):

http://lists.commerce.net/archives/ansi-epay/199905/msg00009.html

Eric Rescorla <ekr@xxxxxxxx>@xxxxxxxx on 07/07/2001 11:54:44 AM wrote:
Lynn.Wheeler writes:
one of the biggest problems that has led to most of the regulations is the
ease that account-number harvesting can occur and then the account number
used in fraudulent, non-authenticated transactions. The SET-like protocols
didn't address this issue.

How so? In at least one mode, SET denied the merchant the PAN.

XML digital signature authentication reference

From: Lynn Wheeler
Date: 07/14/2001 01:52:52 AM
To: internet-payments@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: XML digital signature authentication reference

non-repudiation, was Re: crypto flaw in secure mail standards

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

From: Lynn Wheeler
Date: 07/14/2001 03:41:04 PM
To: "Lewis, Tony" <TLewis@xxxxxxxx>
cc: EKR <ekr@xxxxxxxx>, Greg Broiles <gbroiles@xxxxxxxx>,
jamesd@xxxxxxxx, James M Galvin <galvin@xxxxxxxx>,
    cryptography@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: RE: non-repudiation, was Re: crypto flaw in secure mail standards

the actual reply, when I asked about was posted

(gone 404)
http://lists.commerce.net/archives/ansi-epay/199905/msg00009.html
but lives on at the wayback machine
https://web.archive.org/web/20010725154624/http://lists.commerce.net/archives/ansi-epay/199905/msg00009.html

in thread titled: SSL & SET QUERY" ... from usenet group

It was never even a minor purpose of the SET specification work to eliminate credit card numbers from being known by the merchant.

The fact that the merchant does not see the account number on the way to the payment gateway was touted by some as a benefit of the system, but it was a side effect of the design. There was never a stated (or even implied) requirement to hide the account number from the merchant.

posted Fri, 7 May 1999, 14.59.11 -0700 to ansi-epay@xxxxxxxx by tlewis@xxxxxxxx

"Lewis, Tony" on 07/14/2001 07:56:42 AM writes:
Some acquirers may decide to keep the PAN from the merchant. If they do, they must create an appropriate mechanism to match transactions for disputes.

Tony

lynn.wheeler writes:
>specific ref.
>https://www.garlic.com/~lynn/aepay3.htm#sslset1
>
>in a thread with one of the SET people from visa ... they stated that it
>was not designed to prevent a valid merchant from getting the PAN ..... in
>fact, that there are standard credit card businness process that require
>the merchant to have the PAN and that the PAN was alwas returned to a valid
>merchant from the payment gateway. I had made the assertion that possibly
>the SET option could have been overriden ... which would have inhibited the
>ability of the merchant to perform normal credit card business processing
>... and was corrected that it was always designed that the PAN be returned
>to a valid merchant (and not to inhibit the merchant from being able to
>execute standard business processes).
>
>misc. set references from past discussions
>https://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))
>https://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on DSTU X9.59
>https://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
>https://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
>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#sslset1 "SSL & SET Query" ... from usenet group
>https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
>https://www.garlic.com/~lynn/aepay4.htm#visaset Visa Delicately Gives Hook to SET Standard
>https://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard
>https://www.garlic.com/~lynn/aepay4.htm#3dssl VISA 3D-SSL
>https://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
>https://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
>https://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!
>
>misc. electronic commerce discusions
>https://www.garlic.com/~lynn/aadsm5.htm#asrn2
>https://www.garlic.com/~lynn/aadsm5.htm#asrn3
>
>Eric Rescorla <ekr@xxxxxxxx>@xxxxxxxx on 07/07/2001 11:54:44 AM writes:
>>
>>Lynn.Wheeler writes:
>>>one of the biggest problems that has led to most of the regulations is
>>>the
>>>ease that account-number harvesting can occur and then the account number
>>>used in fraudulent, non-authenticated transactions. The SET-like
>>>protocols
>>>didn't address this issue.
>>How so? In at least one mode, SET denied the merchant the PAN.
>>
>>-Ekr
>>

non-repudiation, was Re: crypto flaw in secure mail standards

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

From: Lynn Wheeler
Date: 07/15/2001 03:03:13 AM
To: "Donald E. Eastlake 3rd" <dee3@xxxxxxxx>
cc: "Lewis, Tony" <TLewis@xxxxxxxx>, EKR <ekr@xxxxxxxx>,
Greg Broiles <gbroiles@xxxxxxxx>, jamesd@xxxxxxxx,
     James M Galvin <galvin@xxxxxxxx>, cryptography@xxxxxxxx,
ansi-epay@xxxxxxxx
Subject: Re: non-repudiation, was Re: crypto flaw in secure mail standards

yes, at the 50k foot level that is about the same protection for SSL (i.e. the percentage of invalid parties in a transaction that see the PAN has been about the same for both SET and SSL).

the (real) issue for the original SSL implementation has not been the percentage of invalid parties accessing the PAN while the transaction is in progress ... i.e. the issue that has been showing up in the press ... is that PANs have been harvested from valid merchant sites.

one of the things that the financial industry's financial payment object standard for all electronic, account-based payments ... was to also address the issue of large number of valid participants in transactions being able to see the PAN and still the PAN-leakage into fraudulent transactions (aka X9A10 working group charter was to preserve the integrity of the financial infrastructure). The result was the financial industry's X9.59 payment object standard for all account-based transactions (aka not just internet and not just credit or debit).

misc. x9.59 information
https://www.garlic.com/~lynn/

random refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

"Donald E. Eastlake 3rd" on 07/14/2001 06:34:21 PM writes:
It is a benegit of SET that the PAN is only going to be seen by authoritzed metchants.

Donald

lynn.wheeler@xxxxxxxx wrote:
>the actual reply, when I asked about was posted
>
>http://lists.commerce.net/archives/ansi-epay/199905/msg00009.html
>
>It was never even a minor purpose of the SET specification work to eliminate
>credit card numbers from being known by the merchant.
>
>The fact that the merchant does not see the account number on the way to the
>payment gateway was touted by some as a benefit of the system, but it was a
>side effect of the design. There was never a stated (or even implied)
>requirement to hide the account number from the merchant.
>
>posted Fri, 7 May 1999, 14.59.11 -0700 to ansi-epay@xxxxxxxx by
>tlewis@xxxxxxxx
>
>"Lewis, Tony" on 07/14/2001 07:56:42 AM wrote
>>
>>Some acquirers may decide to keep the PAN from the merchant. If they do,
>>they must create an appropriate mechanism to match transactions for
>>disputes.
>>
>>Tony
>>
>>lynn.wheeler@xxxxxxxx wrote:
>>>
>>>specific ref.
>>>https://www.garlic.com/~lynn/aepay3.htm#sslset1
>>>
>>>in a thread with one of the SET people from visa ... they stated that it
>>>was not designed to prevent a valid merchant from getting the PAN ..... in
>>>fact, that there are standard credit card businness process that require
>>>the merchant to have the PAN and that the PAN was alwas returned to a valid
>>>merchant from the payment gateway. I had made the assertion that possibly
>>>the SET option could have been overriden ... which would have inhibited the
>>>ability of the merchant to perform normal credit card business processing
>>>... and was corrected that it was always designed that the PAN be returned
>>>to a valid merchant (and not to inhibit the merchant from being able to
>>>execute standard business processes).
>>>
>>>
>>>misc. set references from past discussions
>>>https://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))
>>>https://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on DSTU X9.59
>>>https://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
>>>https://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
>>>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#sslset1 "SSL & SET Query" ... from usenet group
>>>https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
>>>https://www.garlic.com/~lynn/aepay4.htm#visaset Visa Delicately Gives Hook to SET Standard
>>>https://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard
>>>https://www.garlic.com/~lynn/aepay4.htm#3dssl VISA 3D-SSL
>>>https://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
>>>https://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
>>>https://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!
>>>
>>>misc. electronic commerce discusions
>>>https://www.garlic.com/~lynn/aadsm5.htm#asrn2
>>>https://www.garlic.com/~lynn/aadsm5.htm#asrn3
>>>
>>>Eric Rescorla <ekr@xxxxxxxx>@xxxxxxxx on 07/07/2001 11:54:44 AM wrote:
>>>
>>>Lynn.Wheeler writes:
>>>> one of the biggest problems that has led to most of the regulations is the
>>>> ease that account-number harvesting can occur and then the account number
>>>> used in fraudulent, non-authenticated transactions. The SET-like protocols
>>>> didn't address this issue.
>>>
>>>How so? In at least one mode, SET denied the merchant the PAN.
>>>
>>>-Ekr
>>>
>>>--
>>>[Eric Rescorla ekr@xxxxxxxx]
>>> http://www.rtfm.com/

Shared-Secret exploit

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

From: Lynn Wheeler
Date: 07/22/2001 07:16 AM
To: ansi-epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Shared-Secret exploit

Telstra BigPond Passwords Leaked

http://slashdot.org/articles/01/07/22/0558207.shtml

problems with shared-secret based account-management is leakage and harvesting of such information.

This is the same type of problem with news reports about harvesting of financial account numbers that are used in unauthenticated transactions.

recent thread in sci.crypt (PKI/Digital signatures doesn't work) regarding benefit of digital signatures (as opposed to PKI) regarding harvesting & leakage of shared-secret information.

https://www.garlic.com/~lynn/2001g.html#63

... given that the account files contain public key in place of shared-secrets, then the consumer can have some amount of control over the degree of protection they want; i.e. the exploits move from harvesting of information at web sites (over which the consumer has little or no control of the level integrity) to exploits on their personal computing environment (which the consumer can exercise some degree of control).

X9.59 has analogous benefit since it defines account numbers that are no longer shared-secrets but are values that can be only used in authenticated transactions. This removes the exploits associated with PAN-leakage and PAN-harvesting at merchant web sites.

As in the above reference, some the remaining (weakest link) exploits are the ones affecting the individual's personal computing environment. Issues as to virus protection, hardware token vis-a-vis software, etc. ... items that the individual has a possibility of exercising some degree of control.

misc. refs:
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subpubkey.html#privacy

Nacha reports mentions X9.59 payment protocol

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

From: Lynn Wheeler
Date: 08/03/2001 06:14:07 PM
To: dcsb@xxxxxxxx, internet-payments@xxxxxxxx,
     ansi-epay@xxxxxxxx
Subject: Nacha reports mentions X9.59 payment protocol

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

the report
https://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.

Visa Debit Card

From: Lynn Wheeler
Date: 08/06/2001 05:32:50 AM
To: Malte Krueger <malte.krueger@xxxxxxxx>
cc: internet-payments@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: Visa Debit Card

one of the nice advantages of the referenced pilot is the X9.59 support as a standard on its way to ISO in the standardization process ... and the already passed support for inclusion of the operation in the ISO8583 standard aka 8583 is the existing international standard for both the credit and debit financial networks; x9.59 is standard for the payment object, regardless of whether it is credit, debit, atm, or other form of account-based payment & would be targeted for all environments, including both internet and point-of-sale

x9.59 was designed from the inception for a light-weight implementation since a typical 8583 payment message could be as small as 60 bytes ... with some 8583 networks carrying peak load of thousands of such transactions per second. Many other specifications have been extra-ordinarily heavy-weight, especially when it went to mapping them into anything more than trivial pilot activity (aka if you ever tried to scale them to any significant number of transactions) with regard to the existing payment networks.

Malte Krueger on 08/06/2001 02:16:43 AM wrote:
Dear all,

there is also another NACHA approach for internet payments that is already operational. On March 16, 2001 NACHA announced Rules for Secure Internet Payments from Consumer Checking Accounts
http://www.nacha.org/news/news/pressreleases/2001/PR031601/pr031601.htm

The new rules introduce of a new ACH transaction code ? WEB - and put the following obligations on companies wanting to perform internet-initiated debits:
- implement commercially reasonable fraudulent transaction detection systems;
- verify the validity of routing numbers provided by consumers;
- establish a secure Internet session prior to the consumer key entering any banking information; and,
- conduct an annual audit to ensure that financial information obtained from consumers is protected by adequate levels of network and physical security as well as personnel and access controls.

One thing I could not yet find out is how transactions are authorised. If anybody knows something about this I would be grateful for some information.

A question for Chuck:

You wrote
> In fact, many banks issue
> ATM cards that can be used as either an online or offline debit
> card. When one of these dual-use cards is presented to a merchant
> that can accept either online debit or credit cards, the consumer
> gets to decide which type of transaction they would like to make
> (according to industry rules).
> I was a bit confused when I read this. Is it a card that combines online
> debit and offline debit OR online debit and credit?
>

Cheers,

Malte

-----------------------------
Malte Krueger
European Commission
Institute for Prospective Technological Studies (IPTS)
World Trade Center
Isla de la Cartuja
41092 Sevilla
Spain
email: malte.krueger@xxxxxxxx
Tel.: 0034 95 4488 393
Fax: 0034 95 4488 208
URL: http://epso.jrc.es

From September 2001:
PaySys Consultancy GmbH
Im Uhrig 7
60433 Frankfurt/Main
E-mail: PaySys@xxxxxxxx
Tel.: 0049 (0)69 - 95 11 77 - 0
Fax: 0049 (0)69 - 52 10 90
URL: http://www.paysys.de

Visa Debit Card

From: Lynn Wheeler
Date: 08/06/2001 06:24:09 AM
To: Malte Krueger <malte.krueger@xxxxxxxx>
cc: internet-payments@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: Visa Debit Card

note that work on "light-weight" for x9.59 standard was done both in terms of payload weight as well as protocol or "chatter" weight.

in one of the lightest scenerios ... shopping or selection could be done "offline" ... from a local cd-rom or other distributed material ... an order and the associated x9.59 payment object bundled up and sent off (presumably as electronic "instant" message, but "email" wasn't precluded). the merchant or supplier receives the order & payment, after doing whatever is necessary to validate the order, the payment instruction then would be forwarded to the financial infrastructure for authentication & possibly authorization and the response returned to the merchant/supplier ... which then returns a returns a reponse to the purchaser/buyer.

part of the x9.59 work was to support both the lightest weight possible payload while preserving the integrity of the financial infrastructure as well as the lightest weight possible protocol in terms of "chatter" ... i.e. at the simplest being able to execute in a single light weight round trip (w/o any environmental and/or other unecessary protocol chatter and noise).

of course the implied objective of the x9.59 work ... was to also have it supported as a financial industry standard (initially national, but eventually international) ... and not just some industry group specification i.e. on equal footing with things like iso8583 on & other components that the financial industry relies on.

fyi ... Comments requested on ETSI Draft TR "XML format for signature policies"

From: Lynn Wheeler
Date: 08/09/2001 10:04:41 AM
To: ansi-epay@xxxxxxxx
Subject: fyi ... Comments requested on ETSI Draft TR "XML format for signature policies"

Request for comments on draft ETSI TR on XML based Signature Policies:
This draft ETSI technical report defines Signature Policies using XML which are based on the ASN.1 Signature Policies defined in ETSI TS 101 733 and RFC 3125.

This draft TR is offered as a starting point for discussion on XML based Signature Policies. All comments received will help to determine the future direction this work item will take in ETSI. This draft technical report is being made publicly available for review and comment by any company, individual or organisation with interest in this area. A copy can be obtained through the ETSI El Sign web site (see below).

Comments are requested by 14th September.

Background

The development of this technical report

"XML format for signature policies"

is one of the tasks the ETSI Electronic Signature and Infrastructure Working Group is progressing within the European Electronic Signature Standardisation Initiative (EESSI). The ETSI El Sign Web-site (see below) provides further information about the ETSI activities and the EESSI program.

REQUESTED ACTION

Please send your comments and suggestions not later than 14 September to the ETSI El Sign e-mail list EL-SIGN@xxxxxxxx, with copy to the editor on cruellas@xxxxxxxx . Please put "ETSI-XML-SigPol" at the front of the Subject field of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document (STF178Task3DraftTR.pdf) see:

http://www.etsi.org/sec/el-sign.htm

The purpose of the open e-mail list is to stimulate discussion of the published comments and contributions. Therefore, early submissions are welcome. We expect that discussions will go on through the open e-mail list under and after the comments period.

With regards

Juan Carlos Cruellas (Universitat Politecnica de Catalunya)
Editor - XML format for signature policies

cruellas@xxxxxxxx

and

Gy�rgy Endersz, Telia Research AB
Chair ETSI ESI Working Group
gyorgy.g.endersz@xxxxxxxx

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

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

From: Lynn Wheeler
Date: 08/12/2001 11:27:29 AM
To: ansi-epay@xxxxxxxx
Subject: net banking, is it safe?? ... power to the consumer

ref:
https://www.garlic.com/~lynn/2001h.html#58

Net banking, is it safe???

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
 Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
Date: Sun, 12 Aug 2001 15:45:21 GMT

LESLIE@xxxxxxxx (Jerry Leslie) writes:
No system is 100% safe/secure unless it is turned off and physical access denied.

One has to decide that the convenience of on-line transactions is worth the risk, and whether the financial institution is exercising due diligence.

Use of Microsoft's IIS without patches can expose information to criminals. Here's a relevant article:

http://www.theregister.co.uk/content/4/20960.html
Hacking IIS -- how sweet it is

By Thomas C Greene in Washington Posted: 10/08/2001 at 19:29 GMT

"We've looked over a few recent credit-card database compromises brought to our attention by CardCops (formerly AdCops), an organization which tries to get the straight dope on e-commerce hacks directly from the blackhat community to better inform merchants of threats to their systems..."

Although The Register and The Inquirer sites are not 100% accurate, their articles often cite references; e.g.:

http://www.cardcops.com/

Here's a site that might provide some useful info:

http://www.cybercrime.gov/

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

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:

https://www.garlic.com/~lynn/aadsm6.htm#aadsatm

https://www.garlic.com/~lynn/2001h.html#37

https://www.garlic.com/~lynn/2001h.html#53

https://www.garlic.com/~lynn/subpubkey.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).

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

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

From: Lynn Wheeler
Date: 08/12/2001 04:56:37 PM
To: ansi-epay@xxxxxxxx
Subject: net banking, is it safe?? ... security proportional to risk

ref:

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

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
 Subject: Re: Net banking, is it safe???
Newsgroups: comp.security.misc
 Date: Sun, 12 Aug 2001 21:25:22 GMT
Organization: Wheeler&Wheeler

Anne & Lynn Wheeler writes:
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).

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 the 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:

https://www.garlic.com/~lynn/subtopic.html#fairshare

https://www.garlic.com/~lynn/subpubkey.html#privacy

https://www.garlic.com/~lynn/subintegrity.html#fraud

- home

some recent threads on netbanking & e-commerce security

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

From: Lynn Wheeler
Date: 09/04/2001 12:50:06
To: ansi-epay@xxxxxxxx
Subject: some recent threads on netbanking & e-commerce security

Network Identity Alliance -- Liberty Alliance Project

From: Lynn Wheeler
Date: 09/26/2001 12:28 PM
To: ansi-epay@xxxxxxxx
Subject: Network Identity Alliance -- Liberty Alliance Project

recent posting today

note that this has significant overlap with previous discussions regarding being able to be identity agnostic with respect to X9.59 strong authentication ... while still not precluding that transactions can be associated with specific individuals.

radius related discussion about strong authentication while at the same time not having to unncessarily spray identify information all over the place
https://www.garlic.com/~lynn/subpubkey.html#radius

X9.59 discussions with respect to privacy, identity and authentication
https://www.garlic.com/~lynn/subpubkey.html#privacy

http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/09-26-2001/0001579753
PALO ALTO, Calif., Sept. 26 /PRNewswire/ -- ProjectLiberty.org, In an unprecedented collaboration between some of the world's largest businesses and industries, representing over a billion customers, employees and business partners, 33 major companies announced today the formation of an alliance, code named Liberty Alliance Project (http://www.projectliberty.org). The alliance will develop and deploy an open solution for network identity.

The charter members of the Liberty Alliance Project, representing a broad, global spectrum of industries, intend to create an open, federated solution for network identity -- enabling ubiquitous single sign-on, decentralized authentication and open authorization from any device connected to the internet, from traditional desktop computers and cellular phones through to TVs, automobiles, credit cards and point-of-sale terminals. The alliance represents some of the world's most recognized brand names and service providers, driving products, services and partnerships across a wide range of consumer and industrial products, financial services, travel, digital media, retailing, telecommunications and technology.

Any organization interested in supporting the Liberty Alliance Project can visit
http://www.projectliberty.org for details. The Liberty Alliance Project plans to begin immediately in setting out a roadmap to address business practices, privacy, consumer adoption and technology evolution.

"It's recently become clear that the software for managing user identity and authentication is one of the key building blocks of the emerging internet operating system," comments Tim O'Reilly, founder and CEO of technology publisher O'Reilly & Associates and an activist for open source software and internet standards. "It's so fundamental that a widespread consensus has emerged that this is a technology that shouldn't be owned or controlled by any one player. Instead, we need an open, distributed system with implementations available from multiple technology providers and identities issued by many parties operating in a web of trust. Project Liberty is an important step in that direction. I'm hopeful that it will provide a forum for interoperability between the proposed identity schemes available from individual software or service vendors."

"Security and identity are facets of almost every big issue in the digital world today," said Esther Dyson, chairman of EDventure Holdings, and former chairman of ICANN, an organization that sets policy for the Internet's infrastructure, including the Domain Name System. "They touch it all: privacy, anonymity, integrity of data and safety of assets, freedom of speech, legitimacy, trust and trust worthiness, branding, visibility of marketers and visibility to marketers. Therefore, it's important for individuals to have a convenient way to identify themselves (and their counterparts)."

Another Thing to Feer: ID Theft

From: Lynn Wheeler
Date: 10/01/2001 11:08 AM
To: ansi-epay@xxxxxxxx
Subject: Another Thing to Feer: ID Theft

http://www.wired.com/news/conflict/0,2100,47201,00.html

from above:
Identity theft is not only an international problem. According to the FBI, it was the fastest growing white-collar crime of 1999 within the United States. "There were 700,000 cases," Janik said, "some of them potentially crippling situations. For one guy I know it was so serious -- the guy who stole his identity even sold his house."

=======

misc. other refs:
https://www.garlic.com/~lynn/subintegrity.html#fraud Risk, Fraud, Exploits
https://www.garlic.com/~lynn/aepay3.htm#gap2 [ISN] Card numbers, other details easily available at online stores
https://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay6.htm#itheft "Gurard against Identity Theft" (arrived in the post today)
https://www.garlic.com/~lynn/aepay7.htm#fakeid Fake IDs swamp police
https://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
https://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords

With security a sudden priority, 'smart card' technology gets a second look

From: Lynn Wheeler
Date: 10/15/2001 04:31 PM
To: ansi-epay@xxxxxxxx
Subject: With security a sudden priority, 'smart card' technology gets a second look

http://www.siliconvalley.com/docs/news/svfront/017046.htm

Reports of Identity Theft Still Rising Fast

From: Lynn Wheeler
Date: 10/23/2001 08:54 AM
To: ansi-epay@xxxxxxxx
Subject: Reports of Identity Theft Still Rising Fast

misc. past refs:
https://www.garlic.com/~lynn/aadsm7.htm#idcard AGAINST ID CARDS
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aepay3.htm#gap2 [ISN] Card numbers, other details easily available at online stores
https://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay6.htm#itheft "Gurard against Identity Theft" (arrived in the post today)
https://www.garlic.com/~lynn/aepay7.htm#fakeid Fake IDs swamp police
https://www.garlic.com/~lynn/aepay7.htm#idtheft Another Thing to Feer: ID Theft
https://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
https://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001l.html#29 voice encryption box (STU-III for the masses)
https://www.garlic.com/~lynn/subpubkey.html#privacy X9.59, Identity, Authentication, and Privacy

=================== attached from Reuters ...

Monday October 22 12:54 PM ET

Reports of Identity Theft Still Rising Fast

WASHINGTON (Reuters) - The number of identity thefts reported by banks and other financial institutions is on the upsurge again in 2001 after more than doubling last year, according to a new report released on Monday.

3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

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

From: Lynn Wheeler
Date: 10/25/2001 03:57 PM
To: ansi-epay@xxxxxxxx
Subject: Re: 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

oops, had slightly fumble fingered part of the email address

----- Forwarded by Lynn Wheeler on 10/25/2001 03:57 PM -----

To: chris cook <cojock@xxxxxxxx>
 Date: 10/25/2001 11:06 AM
cc: anders.rundgren@xxxxxxxx,internet-payments@xxxxxxxx,
     ansi-eapy@xxxxxxxx
Subject: Re: 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

we have done work on such a chip ... including various kinds x9.84 kinds of support (see aads chip strawman at
https://www.garlic.com/~lynn/x959.html#aads
).

the chip is R/O other than storing biometric templates and/or PIN ... and relatively small amount of other dataspace that is pin/bio protected.

it is targeted for use in all forms of authentication transaction ... including financial of the kind that NACHA recently piloted
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

one of the issues is that since it would do the biometric matching .... it isn't exposed to the heavy security and privacy issues outlined in x9.84 with regard to transmitting biometric values over (open or otherwise) networks and/or aggregating such biometric values in various kinds of repositories. Also, I don't know of any scenerio that biometric templates are reversable into human recognizable information (aka face print biometric template reversed into actual face print).

the financial transaction support is provided by strongly authenticated X9.59 financial transaction which was designed to support all account-based transactions in all environments.

some related risk management & information security discussions
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay3.htm#riskaads

some generic risk, fraud & privacy discussions
https://www.garlic.com/~lynn/subintegrity.html#fraud
https://www.garlic.com/~lynn/subpubkey.html#privacy

part of the issue is that identification and authentication are frequently confused. using identification when authentication is all that is needed typically results in unnecessarily propagating privacy information. Typically a merchant is only concerned with knowing that they will get paid ... (as part of the financial transaction) they don't necessarily need to know anything else. This scenerio is whether it is useful to have privacy information (name & address) associated with financial transaction appear at tens of millions of locations around the world (i.e. merchants) or is it sufficient for the merchant to know that the transaction has been strongly authenticated and will be paid ... and any identification information that might exist only appears at hundreds of locations around the world (i.e. banks as necessary). Then with regard to biometrics ...... which is better 1) biometric values propagated all over the place for correct transaction authentication or 2) knowing that the corresponding hardware token is only working with the appropriate biometric has been entered (and your biometric information never has to leave your local environment).

Part of the issue is that current magstrip debit card PINs typically represent a shared-secret. Contrast that to situation where the PIN is only used between you and your hardware token and the financial infrastructure depends on the operation of the hardware token based on correct pin being used (aka the PIN is a secret but no longer a shared-secret). Simiraly, biometric paradigms can either be implemented as shared-secret infrastructures (where the biometric value effectively becomes a very complex PIN) or a non-shared-secret infrastructure (i.e. shared between just you and your hardware token). The disadvantages of biometric shared-secret paradigm (compared to PIN shared-secrets) is that when a PIN shared-secret is compromised you get to change your PIN .... a biometric shared-secret compromise is much more difficult to correct (and part of the reason that x9.84 devotes some attention to protecting the biometric values when they are implemented in a shared-secret paradigm).

In any case, all of this could be done within the existing account-based financial infrastructures ... using X9.59 transactions that have been authenticated with hardware token digital signatures (i.e. X9.59 has already been designed to be compatible with existing iso8583 and other financial network infrastructures) where the hardware tokens require either a PIN and/or a biometric ... meeting two or more requirements of 3-factor authentication:

1) something you have
2) something you know
3) something you are

w/o needing to spray biometric shared-secrets all over the world. This is also partially covered within the EU FINREAD work for trusted transactions.

misc FINREAD refs:
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?

past biometric discussions on the subject
https://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy are not Antinomies
https://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
https://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp-00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aadsmore.htm#biosigs2 biometrics and electronic signatures
https://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
https://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/99.html#157 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#166 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#168 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000.html#60 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#7 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#30 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#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
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#61 I-net banking security

chis cook on 10/24/2001 8:09 AM wrote:
Anders,

Apologies for going off topic.

I'm working with a MidEast central bank on new payment architecture/infrastructure. My take on things is very much based upon markets generally and how they operate. To me the money market is just another market.

But my fraud/regulation/investigation background has given me a very close interest in the subjects of payment and ID/authentication/encryption etc, but all from a regrettably non-technical background.

I'm a simple guy at heart. Why cannot the following scenario work on a country by country basis?

1/ We all get a payment card with a unique identifying number (which we choose and which doubles as a lottery entry each month as an incentive to use it cf Dutch postcode lottery); 2/ the card has a read only chip capable of storing the data comprised in a

digital photo of the holder; 3/we go and get our card from suitable trusted third party (bonded solicitor/notary public etc revisited) who takes photo, verifies ID etc; 4/ when we do so image is stored in local cache/Neighbourhood Area Network and replicated centrally (vision here of electronic ghost image following us about the country from local cache to local cache); 5/all POS terminals have readers which bring up image of customer, so dozy checkout operator has to look at it; 6/ over certain limit/randomly/just for the hell of it the POS operator can/must request matching image from local cache/central to check match; 7/all ATM's have cameras plus face recognition software if it's up to the task and run a match each time, plus central match possibility.

Naturally you also overlay all the PIN and other additional features.

For mobile payments you use similar methodology but with voice recognition data held centrally and replicated on the SIM.

Probably the technology isn't there yet, or has someone already tried any or all of the above?

(NB I know data flow is an issue. I have a very close interest in new "Broadcast Web" platform (www.enfocast.com) which broadcasts data bypassing

the web and is a key part of the proposed architecture.)

Finally, FYI my take on new payment architecture generally.

Very simple and straightforward proposition.

Payment ie exchange of value, is a utility (and should not "belong" to anyone least of all the Banks), and every individual, and every business, will be entitled to a basic payment facility operated for and on behalf of the Central Bank of his country.

Underpinning this facility will be:
(a) a core central processing engine backed by a "central" financial transaction repository (decentralised in due course);
(b) a database of identities (for corporates, that is simply the Company Registry);
(c) (and this is purely my take on monetary systems)electronic money consisting of shares issued by the Central Bank and backed by sovereign assets and income (as opposed to debt-backed currency).

Because payment, uniquely, requires ID. Everything else may require payment, but not necessarily ID.

Regards

Chris Cook

3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

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

From: Lynn Wheeler
Date: 10/25/2001 05:01 PM
To: internet-payment@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

The other disadvantage of biometrics in a shared-secret paradigm is that ... compared to the PIN-shared-secret scenerio ... where you are asked to have a different (shared-secret) PIN/passowrd for every security domain you operate in .... it is somewhat more difficult to have a different (shared-secret) biometric for each distinct secure environment.

also with respect to earlier comment on vulnerability analysis

https://www.garlic.com/~lynn/aepay7.htm#netback2 net backing, is it safe? ... security proportional to risk

lynn wheeler on 10/24/2001 11:06 AM wrote:
(i.e. shared between just you and your hardware token). The disadvantages of biometric shared-secret paradigm (compared to PIN shared-secrets) is that when a PIN shared-secret is compromised you get to change your PIN .... a biometric shared-secret compromise is much more difficult to correct (and part of the reason that x9.84 devotes some attention to protecting the biometric values when they are implemented in a shared-secret paradigm).

financial payment standards ... finger slip

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

From: Lynn Wheeler
Date: 10/26/2001 08:59 AM
To: internet-payments@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: financial payment standards ... finger slip

oops
https://www.garlic.com/~lynn/aepay7.htm#netback2 net backing, is it safe? ... security proportional to risk

that should be
https://www.garlic.com/~lynn/aepay7.htm#netbank2

with regard to authentication and identification ... the requirement given the X9A10 working group for the X9.59 standard was that it
preserve the integrity of the financial industry for ALL electronic retail payment transactions without encryption (just authentication). That is ALL ... as in ALL, i.e. internet, non-internet, point-of-sale, debit, credit, ach, etc.

3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

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

From: Lynn Wheeler
Date: 10/27/2001 09:57 AM
To: internet-payments@xxxxxxxx, ansi-epay@xxxxxxxx
Subject: Re: 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

As an aside with regard to vulnerabilities .... X9A10 having been given the requirement that X9.59 preserve the integrity of the financial infrastructure for ALL electronic retail payment transactions looked at some of the other implementations out there.

From a vulnerability analysis stand-point it appeared that basic security tenets would require:

KISS
end-to-end security & authentication
single transaction for both authentication and authorization

i.e.

the more complex the operation and the more parts the bigger the chance something goes wrong and there is a failure
lack of single end-to-end operation increases the chances that something goes wrong and the bad guys can take advantages created by the "cracks" in the system created by non-end-to-end security and authentication
if the same single transaction does not have the same authentication for both message authentication and sender authentication ... which also is the basis for authorization ... then there are likely to be cracks in the system that the bad guys can take advantage of. That is why most properly formed security designs and implementations have a single authenticated message that flows end-to-end and doesn't do poorly designed security implementations like splitting things up into a separate authentication message and an unathenticated authorization message.

Another side-point of #3 was that it significantly reduced the protocol chatter and complexity (as well as the possible failure modes) so that it did actually fit into multiple environments. Since it had a single end-to-end authenticated authorization message ... besides the various web-based deployements it also supported things like

a) cdrom email purchases over the internet ...i.e. an X9.59 authenticated message with purchase request could be sent in email and the whole procedure could happen in a single round trip (i.e. consumer to merchant, merchant to financial infrastructure, reply back to merchant, reply back to consumer)

b) pos/point of sale, single dial-up transactions. The current pos terminal could originate a single dial-up authenticated transaction ... send it off for authentication & authorization; authenciation of the authorization request is performed, and reply made.

In general, most beginning security basics will teach that separation of authenication and authorization creates vulnerability opportunities and cracks in the security (aka ... not having the authorization request directly authenticated).

Unified Modeling Language (UML) for NACHA Business Models & XML Project

From: Lynn Wheeler
Date: 11/16/2001 09:29 AM
To: ansi-epay@xxxxxxxx
Subject: Unified Modeling Language (UML) for NACHA Business Models & XML Project

https://web.archive.org/web/20020203153720/http://internetcouncil.nacha.org/Projects/default.html
Unified Modeling Language (UML) for NACHA Business Models (.doc)

The objectives of this project are to apply the techniques and tools of UML to the NACHA business models for various payment types and produce a set of UML documents and diagrams that can be used by the NACHA community in educational and analytical contexts. The benefits of this project are to make it simpler to compare and contrast payment mechanisms in terms of their interaction and risk allocation and may prompt more complete dialogue on modeling and specification of payment systems. The deliverable of this project is a set of UML models for ACH payments, which would depict the flow from various NACHA participant perspectives, including Originator, ODFI, RDFI, Receiver, and ACH Operator.

XML Project

The purpose of the XML project is to produce a white paper examining the feasilibilty of transporting XML-formatted data through the ACH Network. Members of the XML project have broken into subgroups to work on individual chapters of the white paper. Currently, these subgroups are developing the XML Introduction, Dialects, and NACHA Participant Impact sections and have had several conference calls and preliminary writing assignments.

We have made a great deal of progress; yet, much work remains. The remaining work includes the following tasks:

Complete the XML Introduction, Dialects, and NACHA Participant Impact sections. Begin work on other sections including developing the business case for why transporting XML through the ACH is a good idea. Integrate sections into a single document and initiate a revisions process for white paper. Finalize white paper. Participants plan to have an initial draft completed in time for the September 19-21 Internet Council meeting.

NACHA's Board requested that this project be completed as soon as possible, because it is working on an inititive to define a Next-Generation ACH and is keenly interested in the XML Project.

If you are interested in learning more about the project or participating, please send an email to Stephen Ingram. It is necessary to be a member of the Internet Council to participate in Internet Council projects. For membership information, please click here.

X9.59 paper ... fyi

From: Lynn Wheeler
Date: 11/27/2001 11:25 AM
To: ansi-epay@xxxxxxxx
Subject: X9.59 paper ... fyi

information security group at oregon state university

http://www.security.ece.orst.edu/

has a number of papers

http://www.security.ece.orst.edu/publications.html

including "consepp" to be given in two weeks at IEEE Computer Security Conferenece.

http://www.security.ece.orst.edu/papers/c24consp.html
CONSEPP: Convenient and secure electronic payment protocol based on X9.59

A. Levi and C. K. Koc

Proceedings, The 17th Annual Computer Security Applications Conference, to appear, New Orleans, Louisiana, IEEE Computer Society Press, Los Alamitos, California, December 10-14, 2001.

Abstract

The security of electronic payment protocols is of interest to researchers in academia and industry. While the ultimate objective is the safest and most secure protocol, convenience and usability should not be ignored, or the protocol may not be suitable for large-scale deployment. Our aim in this paper is to design a practical electronic payment protocol which is both secure and convenient.

ANSI X9.59 standard describes secure payment objects to be used in electronic payment in a convenient and secure way. It has many useful convenience features for large-scale consumer market deployment, the best being the elimination of consumer certificates. Consumer public keys are stored in account records at financial institutions; the digital signatures issued by consumers are verified by financial institutions. Encryption is deliberately not provided by X9.59.

In this paper we propose a new Internet e-payment protocol, namely CONSEPP (CONvenient and Secure E-Payment Protocol), based on the account authority model of ANSI X9.59 standard. CONSEPP is the specialized version of X9.59 for Internet transactions (X9.59 is multi-purpose). It has some extra features on top of the X9.59 standard. X9.59 requires merchant certificates; in CONSEPP we propose a lightweight method to avoid the need for merchant certificates. Moreover, we propose a simple method for secure shopping experience between merchant and consumer. Merchant authentication is embedded in the payment cycle. CONSEPP aims to use current financial transaction networks, like VisaNet, BankNet and ACH networks, for communications among financial institutions. No certificates (in the classical sense) or certificate authorities exist in CONSEPP. Convenience is not traded for security here; basic security requirements are fulfilled in the payment authorization cycle without extra messaging and significant overhead.

x959 Postings and Posting Index,
next, previous - home