on of the issues in the account/identity fraud scenarios is that
just knowing the PAN allows fraudulent transactions to be performed.
you start to see things like harvesting of merchant transaction
files that provide PANs for fraudulent transactions. recent studies
have indicated that possible at least 77 percent of such harvesting
involves insiders.
part of the scenario is the security versus risk discussed in
this posting about merchant transaction file harvesting ans
security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61
on of the requirements given the x9a10 working group for x9.59
standard was to preserve the integrity of the financial infrastructure
for all retail payments. the resulting x9.59 standard
http://www.garlic.com/~lynn/index.html#x959
uses digital signature to authenticate retail transactions (regardless
of kind, including iso 8583 payment transactions) but doesn't mandate
the horrendous payload bloat of attaching a redundant and superfulous
relying-party-only certificate.
x9.59 also specifies that account numbers that are used in x9.59
transactions can not be used in non-authenticated transactions.
the result is that it is no longer possible to perform fraudulent
payment transactions just by learning an account number. the scenario
then is that if it is no longer possible to perform fraudulent
transactions by harvesting (x9.59) account numbers from merchant
transaction files then it is no longer necessary to maintain
such high security infrastructures to prevent crooks from acquiring
knowledge of account numbers.
we've referred to this being privacy or identity agnostic
as opposed to truely anonymous. there is still an account number
floating around ... but typically has no other identifying
information ... unless somebody gets a court order to acquire
the information from your financial institution. misc references
to privacy, identity, x9.59, etc
http://www.garlic.com/~lynn/subpubkey.html#privacy
misc. past postings mentioning privacy/identity agnostic:
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption
Empower These Terrorists?
http://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance --
Liberty Alliance Project
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing
Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital
certificates in Banias
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national
ID card?
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national
ID card?
http://www.garlic.com/~lynn/aadsm18.htm#22 [anonsec] Re: potential new IETF
WG on anonymous IPSec
at 9/18/2004 11:32 pm anders wrote:
Paulo
I may have lost the safecode stuff.
I have no detailed description of EMV but that is probably easy to
get on the net.
But I essentially described a multi-application smart card which could
hold a credit-card function, a purse and in this case also an identity
function using PKI.
Since the card does not have a display or keyboard etc. there is no
way to select what resource the card reading app is to use. It is
therefore assumed that this is hardcoded into applications or that
applications offer this selection. However, you cannot do a selection
without having parts of the available resources accessible. In the
case of the ID-application it is actually your full identity!
To allow any merchant to monitor a card holder's identity is in
to some extent already possible due to the PAN code, but to *extend*
this feature seems to clearly be a step in the wrong direction.
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
