massive data theft at MasterCard processor

[Anne & Lynn Wheeler]

Charles M. Hannum wrote:
> As long as the "credit card" has no display, you're still trusting the 
> terminal to give the purchaser correct information.  If you're using a smart 
> "credit card" that participates directly in the transaction, storing 
> transaction data, signed by the processor's system, on the card would be 
> useful for repudiation.  You could even have a way of downloading the data 
> directly into Quicken and using it to check invoices automatically.

absolutely ... see comment at end of early post in this thread about
paranoid consumers ...
http://www.garlic.com/~lynn/aadsm19.htm#38

as part of the charge to x9a10 financial standards working group to
preserve the integrity of the financial infrastructure for all retail
payments (aka debit, credit, ach, stored-value, etc as well as internet,
pos, face-to-face, moto, etc) ... there were some other provisions in
x9.59 payment standard
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

for use with private PC-based internet transactions and/or enhanced
personal point-of-sale device (cellphone, pda, etc). there is a data
field defined in the x9.59 that was specifically put in place for use as
personal transaction number (or a virtual check number if you are so
disposed).

it was specifically designed for supporting electronic reconciliation
between transactions and various possible electronic statements.

in the mapping from x9.59 to iso 8583 payment transaction description
http://www.garlic.com/~lynn/8583flow.htm

it is referred to as a LUID (costomer/locally unique number) ...
although there is not actual requirement for it to be unique and/or even
anything other than NULL. the standard suggests that if the LUID field
is present as part of an x9.59 transaction, that the institution should
include it any statements provided the customer (analogous to the way
that check numbers are provided on statements).

X9.59 also provides for an optional field for hash of order detail.
basically what the user signs, can include the hash of the
invoice/order. the merchant then is to validate that any (non-null)
invoice/order hash included in the signed x9.59 message corresponds to
hash of their invoice/order ... if the two hashes don't match ... don't
submit the transaction for payment. If the merchant disputes the
invoice/order later ... and the user happens to have included the hash
of invoice/order in the payment transaction ... then the disputed
invoice/order submitted by the merchant better have a hash that matches
what is in the signed payment transaction. this avoids requiring that
the invoice/order has to be part of the payment transaction ... but
leaves around some amount of detail that can be used as supporting
evidence in the event of any dispuate.

there is a EU FINREAD standard for a personal financial termainal that
talks about countermeasures for things like keylogging and making sure
the value of the transaction is correctly displayed
http://www.garlic.com/~lynn/subpubkey.html#finread

from the x9.59 perspective, there was a lot of work on allowing that
such a terminal could co-sign the transaction ... providing the
financial institution some risk indication about the person
authenticating the transaction as well as risk indication about the
environment in which the transaction occured (aka EU FINREAD specified
requirements for the personal financial termainal ... but didn't
actually require proof that such a terminal was actually used).

some of the characteristics of the EU FINREAD terminal are similar to
the security module requirements for POS terminals. The issue is that
both the users as well as the financial institutions may have no
indication that a POS terminal with specific integrity level was in use
for any specific transaction (making it difficult to fully do
parameterized risk management ... i.e. calculate all the possible fraud
and risk factors on a transaction by transaction basis).

the identified issue leading up to the privatly owned display and keypad
at POS ... is that even if there was a tamper resitent security module
in a tamper resistent post-of-sale terminal ... that also co-signed the
transaction ... there is still POS vulerability with things like
overlays (i.e. a compromised MITM display/keypad sitting between the
user and the real POS secure terminal).


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