[FYI] Did Encryption Empower These Terrorists?

lynn.wheeler at firstdata.com lynn.wheeler at firstdata.com
Tue Sep 25 11:29:20 EDT 2001



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:
ttp://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" <em at who.net> on 9/25/2001 07:45 AM wrote:

"Steven M. Bellovin" <smb at research.att.com> 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





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list