ID "theft" -- so what?
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ID "theft" -- so what?
Date: Fri, 15 Jul 2005 11:44:45 -0600
To: Ian Grigg <iang@xxxxxxxx>
CC: Aram Perez <aramperez@xxxxxxxx>,
cryptography@xxxxxxx
Ian Grigg wrote:
Personally, I call "what PGP does" a Web of Trust.
And I call what browsers do a PKI. The fact that
there is "trust" in PKI and there is "infrastructure"
in WoT is an issue, yes, but we have to have some
sense of differentiation; and those terms are what
the people in those fields tend to be comfortable
with.
simple, PKI basically was designed for situations where you trusted
somebody else to do your trusting ... this is the letters of credit
paradigm from the sailing ship days. most modern business processes go
to great deal of trouble to manage their own trust ... they have
account databases, relationship management systems, accounts
receivable, accounts payable, etc, etc ...
these business operations with their own well established trust
infrastructure ... are in need of better authentication technology.
public/private key and digital signature business process can supply
that better technology.
a lot of PKI likes to focus on PKIs being able to supply organizations
with a trust infrastructure ... so the organizations can avoid
developing their own trust infrastructure.
the truth is that very few business operations actually lack a trust
infrastructure. however, many have a need for upgrading the
authentication technology in their existing trust
infrastructures. PKIs like to get them focused on such technology
upgrade actually mandating creating a (duplicate redundant and
superfluous) PKI trust infrastructure.
there has been significant financial incentive for PKIs to propagate
the concept that they are the only kind of real trust infrastructure
in existance. when they can't avoid acknowledging that a business
operation might already have an existing trust infrastructure
... frequently there is recourse to obfuscation, trying to imply that
the PKI-based trust infrastructures carry magical properties that
other trust infrastructures will never be able to have.
the limits of crypto and authentication
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the limits of crypto and authentication
Date: Fri, 15 Jul 2005 12:13:35 -0600
To: Rich Salz <rsalz@datapower.com>
CC: Aram Perez <aramperez@mac.com>,
cryptography@metzdowd.com
ref:
http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and authentication
a harder problem for early stage web merchants was getting a merchant
financial institution .... the merchant financial institution that
sponsors a merchant for payment transactions ... takes financial
responsibility for that merchant.
the standard procedure was to send somebody out to the retail
brick&morter and do an asset inventory ... to see if the merchant
went under ... that there would be enuf assets left to help cover the
merchant financial institutions losses.
retail web merchants might have nearly zero assets ... they leased
time with a webhosting and fulfillment was outsourced ... so there was
no onhand inventory and effectively no assets. if they were totally
unsuccesful ... then the merchant financial institution would have
little outstanding transaction financial liability.
there were cases where merchant financial institution would try and
cancel a merchant as it became succesful ... since the outstanding
transaction liability for the merchant financial institution could be
going way up ... with no increase in assets to cover the finanical
institution's outstanding liability.
for such "high risk" merchants ... the merchant financial institution
discount might actually be bigger than the MOTO discount ... or any
difference between MOTO and card-present.
early web merchants tended to be existing brick&morter operations
where web MOTO ("mail-order/telephone-order") transactions were not
separated out from non-web MOTO transactions.
there were all sorts of strategy meetings in the '95 time-frame, brain
storming about how to get a bank's financial risk department to even
approve purely web merchant signup (and MOTO vis-a-vis card-present
wasn't a primary issue).
misc. past posts mentioning merchant financial institution:
http://www.garlic.com/~lynn/ansiepay.htm#x959demo X9.59/AADS demos operational
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aepay11.htm#65 E-merchants Turn Fraud-busters (somewhat related)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aadsm18.htm#15 In Search of Eve - the upper boundary on Mallory
http://www.garlic.com/~lynn/aadsm19.htm#39 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#19 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#14 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#17 The Worth of Verisign's Brand
the limits of crypto and authentication
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Fri, 15 Jul 2005 12:35:29 -0600
To: Aram Perez <aramperez@xxxxxxxx>
CC: cryptography@xxxxxxxx
Aram Perez wrote:
One other point, SET did NOT require certs for the consumers. The
client-merchant protocol supported clients without certs.
there was a later "set-lite" w/o certs for clients ... but the
original specification had client certs as part of the core process.
note that the SET consumer certificate was NOT a x.509 identity
certificate ... because of stated reasons regarding privacy and
liability. It was a relying-party-only certificate that basically
contained the account number and the public key
http://www.garlic.com/~lynn/subpubkey.html#rpo
It was also, not a true PKI ... since it didn't have any certificate
administration and management infrastructure. It was purely a
certificate manufacturing process (a term we had coined to
differentiate the early SSL certificate operations from what had been
defined for a PKI operation). Further, the statement was that they
could get by w/o a PKI operation ... since it was purely a
certificate manufacturing process using relying-party-only
certificates (containing just the public key and account number), the
business process could be managed by deactivating the account number
in the real, real-time, online operation.
note the attached reference is dated 3/22/1999 ... and comments
about SET being deployed two years earlier ... aka spring 1997;
compared to the 1994 original deployment for SSL
quicky search engine for set-lite:
http://iugsun.cs.uni-dortmund.de/lehre/datenschutz/material/folien/dsss2004-5-ecommerce.pdf
http://www.it.murdoch.edu.au/~smr/honours/admin/info/DavidsProposal.html
http://www.indiainfoline.com/bisc/ieps.html
http://www.networkworld.com/archive/1999/61423_03-22-1999.html
from above:
When MasterCard and Visa unveiled technology for secure Internet
electronic commerce transactions two years ago, they thought it would
take over the world.
But while Secure Electronic Transaction (SET) has made inroads in
Europe and Asia, it has faltered badly in the U.S. Faced with
technical and business obstacles to SET, MasterCard and Visa are now
coming up with alternatives to SET - SET Lite and Merchant-originated
SET (MOSET).
But SET Lite and MOSET critically alter the SET 1.0 architecture and
soften SET's rock-hard security - all for the sake of convenience. For
example, the technologies abandon the idea that each online consumer
is going to have a bank-issued SET digital certificate for credit-card
encryption. This certificate was to be the main means of verifying the
consumer's real identity on the Internet.
... snip ...
the limits of crypto and authentication
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Fri, 15 Jul 2005 13:05:11 -0600
To: Ram A Moskovitz <ram0502@xxxxxxxx>
CC: cryptography@xxxxxxxx
Ram A Moskovitz wrote:
Did you consult for First Data Corp. at the time?
some reference:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
little later, we got to review chaum and brand stuff. brand had done a
take-off on chaum's stuff so that if somebody double-spent (aka fraud)
... the financial institution could determine who did it (basically a
form of solving two equations in two unknowns).
the limits of crypto and authentication
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Sat, 16 Jul 2005 10:48:14 -0600
To: cryptography <cryptography@xxxxxxxx>
CC: Aram Perez <aramperez@xxxxxxxx>
Anne & Lynn Wheeler wrote:
But SET Lite and MOSET critically alter the SET 1.0 architecture and
soften SET's rock-hard security - all for the sake of convenience. For
example, the technologies abandon the idea that each online consumer is
going to have a bank-issued SET digital certificate for credit-card
encryption. This certificate was to be the main means of verifying the
consumer's real identity on the Internet.
ref:
http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication
note that the bank-issued consumer SET digital certificate ... wasn't
used for credit-card encryption. the original set had this terribly
convoluted process where the consumer encrypted some of the stuff with
the merchants public key and other stuff with the processors
public key.
the consumers relying-party-only digital certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo
was used for the client to perform something you have authentication
... aka digitally signing with the corresponding private key (aka the
verification of the digital signature implies that the signer has
access and use of the private key)
since it wasn't an x.509 identity certificate, didn't contain any
personal information, and was purely a relying-party-only certificate
... there was no real identity on the internet (avoiding raising
horrible privacy and liability issues).
futhermore, since it was a simple relying-party-only certificate, it
is trivial to demonstrate that it is redundant and superfluos ... aka
just flow the transaction thru to the consumer's bank ... and they can
validate the digital signature using the onfile public key. it isn't
necessary for the consumer to repeatedly append a relying-party-only
certificate to possibly thousands of transactions ... for transmission
back to the issuing institution ... which has the original onfile;
especially when the redundant and superfluous relying-party-only
certificate can represent a payload bloat of one hundred times.
note that the referenced article is dated 1999/3/22 and references the
original SET 1.0 deployment (full blown redundant and superfluous
relying-party-only customer certificates) two years earlier (spring
1997). The draft 1.0 specification had appeared spring 1996, initial
prototype appeared early fall 1996, and dedicaed demo systems showed
up at floor shows by the end of 1996.
the other reference indicates that browsers with ssl support appeared
late 1994 with big announcement the spring of 1995.
http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and
authentication
a trivial side-note ... since the SET specification wasn't issued by a
sanction standards body ... it wasn't a Standard in the official
sense.
one of the operational differences between SET and x9.59 financial
industry standard ...
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy
is that x9.59 has an operational rule that account numbers used in
x9.59 transactions can't be valid in non-x9.59 transactions .... which
eliminates the requirement for horrendous amounts of cryptography as
countermeasure for evesdropping of transactions during transmission
(since evesdropping of the transactions doesn't provide an attacker
with sufficient information to perform fraudulent transactions). As a
by-product, it also eliminates the threats and vulnerabilities from
data-breaches ... where there is insufficient information in logged
transactions for a crook to perform fraudulent transactions.
In the SET scenario ... even when the transaction is authenticated
using digital signature ... there was still a requirement for horribly
complex cryptographic implementation as countermeasure to attacker
evesdropping the transaction and using the gained information to
perform fraudulent transactions.
There is an issue where both account fraud and identity fraud have
been lumped under global identity theft label. In the strict account
fraud case, the attacker just needs to obtain sufficient information
to perform fraudulent transactions (against existing accounts) w/o
necessarily obtaining any real personal information.
While SET avoided the horrible privacy and liability issues with real
x.509 identity certificates by using relying-party-only certificates
... it was still subject to account fraud where crooks obtaining
access to information from transaction (either data-in-flight or
data-at-rest .... aka data breaches) have access to sufficient
information for performing fraudulent transactions.
In contrast, x9.59 is signifcantly simpler and represents
significantly lighter payload ... and even eliminates the need to
provide security confidentiality for transactions as countermeasure
against attackers (both in the data-in-flight as well as the
data-at-rest cases) looking at performing account fraud
transactions.
past posts mentioning x9.59 & business rules:
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki11 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
http://www.garlic.com/~lynn/2002n.html#14 So how does it work... (public/private key)
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network Security", Paul Reid
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
the limits of crypto and authentication
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Mon, 18 Jul 2005 10:07:47 -0600
CC: cryptography <cryptography@xxxxxxxx>,
Aram Perez <aramperez@xxxxxxxx>
ref:
http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
one of the issues raised in the x9.59 business rule case was whether
there are sufficient PANs (account numbers) to be able to temporarily
be able to issue two PANs for every account; one PAN useable against
account in X9.59 transactions and one PAN useable against account in
non-X9.59 (legacy, non-authenticated) transactions.
there was some issues raised about having multiple PANs pointing at
the same account ... but that is in wide-spread use already as normal
business practice.
Note that during any transition to secure x9.59 transaction ... the
worst case scenario is that there would be two PANs in existance for
every account. The issue raised whether the account number space is
large enuf to have two PANs for every account (note that if this turns
out to be a real issue ... it would also be a much larger problem for
one-time-PAN implementations ... where you might have hundreds of PANs
mapped to the same account).
The problem for an X9.59 transition is actually somewhat less severe.
Part of the current PAN strategy is stacked against re-use of a PAN.
However, in the x9.59 transition case, I would claim that PAN re-use
is much less of a problem
- re-use of any PAN for x9.59 use .... automatically disables the PAN
for all non-x9.59 use (if the PAN had some lingering legacy attachment
... that woulc be disabled as soon as it was assigned for x9.59 use)
- re-use of a previously assigned x9.59 PAN for x9.59 use ... could
happen on somewhat accelerated schedule ... since the previous x9.59
PAN use would have been associated with a public key that was no
longer active.
the lingering issue as dangling business process associated with old
transactions that are bound to a specific PAN. re-use of PANs need to
after any such dangling business processes have been assured to have
expired.
the upside is that any transition to x9.59 would then give the
consumer some choice and/or control ... strict use of x9.59
transactions would give the consumer some protection against most
skimming, havesting and data breach threats and vulnerabilities. such
a consumer might then want any non-x9.59 PANs to have very strict use
limits (akin to some of the customer specified limits available on
pin-debit accounts ... or what is available on dependent cards).
the limits of crypto and authentication
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Tue, 19 Jul 2005 13:20:47 -0600
To: Jaap-Henk Hoepman <jhh@xxxxxxxx>
CC: cryptography@xxxxxxxx
Jaap-Henk Hoepman wrote:
Actually, Dutch banks already give users the option to recieve
one-time pass-codes by SMS to authenticate internet banking
transactions (instead of sending a list of those codes on paper by
ordinary mail in advance). So it's less unrealistic than you think.
there is also the EU bank challenge/response scenario (requires
two-way communication protocol chatter). the customer initiates a
transaction ... on the internet or even over (voice) phone. the bank
responds with a challenge which is entered into a calculator sized
device and the display comes back with the response. the response then
is either typed or the keyboard (or the phone keypad).
basically it is a relatively dumb pin-pad sleave that a chipcard slips
into ... some old post visiting the company that makes the devices:
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
ID "theft" -- so what?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ID "theft" -- so what?
Date: Thu, 21 Jul 2005 10:28:33 -0600
To: Jeffrey I. Schiller <jis@xxxxxxxx>
CC: Jerrold Leichter <jerrold.leichter@xxxxxxxx>,
John Denker <jsd@xxxxxxxx>,
"Perry E. Metzger" <perry@xxxxxxxx>, cryptography@xxxxxxxx
Jeffrey I. Schiller wrote:
Btw. There are credit card issuers (AT&T Universal is one) that
permits you to create a virtual one-time use credit card (with a time
limit and $$ limit if you want).
So when I shop at a merchant I don't want to trust, I open another
browser window and go to my issuers website and obtain a one-time card
number and use it at the merchant site. I can usually see immediately
after the purchase that the card has been used (on the issuers website)
so I know the merchant is checking the card in real time.
Apparently there is wallet software that will do this in a more
automated fashion, but it isn't available for my platform (non-Windows).
an analogy i've used recently with respect to userid/password
paradigm,
http://www.garlic.com/~lynn/2005m.html#42 public key authentication
is that account numbers are being concurrently used for both the
userid function (requiring security integrity but not security
confidentiality) as well as the password function (requiring strong
security confidentiality). as a result there are frequently
diametrically opposing requirements where the muiltitude of
userid-type business functions require access to the account number
... at the same time, the password-type functions require that the
account number be kept strictly confidential and not be available at
all.
the x9a10 working group was given the requirement to preserve the
integrity of the financail infrastructure for all retail payments. the
resulting x9.59 protocol
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
- allowed for single round-trip, straight-through processing found at
many point-of-sale ... w/o requiring extraneous protocol chatter
- created a strictly enforced separation of the account number as a
userid-type function from digital signature as a password-type function
this eliminated the strongly conflicting goals of very weak
confidentiality requirement for use of the account number in the
multitude of userid-type business processes at the same time having a
very strong confidentiality requirement for the same account number
in its role as passoword/authentication.
this had the downside that there was potentially a maximum of two PANs
allocated for the same account during some transition period (where
both legacy, conflicting use of an account number was required and the
new x9.59 use of an account number requiring separate authentication).
it was startling that some of the strongest opponents of x9.59
claiming that there wasn't large enuf PAN space available to have a
maximum of two PANs per account (during some transition periods)
... subsequently were strong backers of one-time-use PANs ... which
might result in potentially hundreds of PANs being mapped to the same
account.
http://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
Qualified Certificate Request
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Qualified Certificate Request
Date: Thu, 21 Jul 2005 12:20:51 -0600
To: pg@xxxxxxxx
CC: cryptography@xxxxxxxx
Philipp Gühring wrote:
Regarding the requirements for qualified certificates, the only
obstacle we still have is the problem, that CAcert has to make sure,
that the private key for the certificate is generated and stored
securely in a SmartCard, or another Hardware Token. Since the users
should be able to issue the certificates at home, we need a
technical solution to make sure, that the private key is from within
a SmartCard, when we receive a certificate request.
aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads
took a different approach ... the key pair is generated during the
power-on chip test process ... before the wafer is even sliced and
diced and the public key becomes an attribute of the chip (along with
some number of other individual chip specific integrity
characteristics).
the resulting digital signature from the token isn't intended to
represent who you are ... it is intended to provide something you
have authentication ... aka the verification of the digital signature
then implies that the individual has access to and use of the
corresponding private key (and the specific hardware token that
contains it). the private key is never divulged and the public key and
the digital signature represent characteristics of the something you
have authentication.
the public key can be registered ... and there is a service that
allows a relying party to retrieve the integrity characteristics of
the hardware token associated with the public key.
the issue is that the majority of the existing business processes go
to a great deal of trouble binding an identity to some set of business
process characteristics. the incremental issue for the majority of the
business processes in the world ... isn't with respect to who an
individual is ... but what are all the integrity and assurance
characteristics associated with the actual authentication business
processes.
the overall integrity and assurance characteristics associated with
hardware token public key digital signatures ... includes (at least)
the current time-varient characteristics of the specific chip
(apparently identical hardware tokens might have different chip
generations with different assurance characteristics depending on the
date/time of the manufacture of the specific chip), the key length, the
particular digital signature algorithm, the environment in which the
digital signature occured, whether the hardware otken performed a
digital signature with or w/o an associated PIN entry or with or w/o
an associated biometric entry.
I've frequently asserted in the past that some number of PKI-oriented
interests have muddled and obfuscated the fundamental assurance issues
that most business processes have a real need-to-know ... and attempted
to substituted things that certification authorities might be doing when
certification of information for inclusion in a digital certificate.
However, for the majority of things that have been talked about for
stuff that goess into certificates (like information for x.509
identity certificates) ... is stuff that duplicates operations by long
existing and well established business process relationship management
infrastructures.
One might conjecture that since most such PKI-oriented deployments
didn't provide the components of the end-to-end actual authentication
environment (hardware tokens, singing environments, validation
environments) ... that it was in their interest to maximize the
perceived value of the (mostly redundant and superfluous digital
certificates duplicating existing business process of long existing
and well established relationship management infrastructures) digital
certificates and minimizing the perceived value of the other really
important assurance components of interest to relying parties.
ID "theft" -- so what?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ID "theft" -- so what?
Date: Thu, 21 Jul 2005 16:48:49 -0600
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
CC: Jeffrey I. Schiller <jis@xxxxxxxx>, John Denker <jsd@xxxxxxxx>,
Perry E. Metzger <perry@xxxxxxxx>, cryptography@xxxxxxxx
Jerrold Leichter wrote:
If this is all you need, then using a 1-way hash of the card number
for identification and the card number itself for security would
give you much of what you need. There are databases out there which
identify customers by their CC numbers, not because they are willing
to use the stored CC number for charging, but just becauses it's a
good unique ID. If what were stored were the 1-way hash, there
would be nothing worth stealing in the database. This kind of thing
is actually implemented, though people rarely think of it in these
terms. You can see it on many printed charge slip these days: Your
CC number no longer appears, being replaced by a one-way hash that
produces 12 X's and the last 4 digits of your number. Hardly
cryptographically strong in the usual sense, and not generally
applicable, but for ID purposes - letting you identify which of your
cards you used when making the charge - this particular one-way hash
is perfectly good. (It's also common on Web forms that tell you
which of your cards a charge will be applied to.)
there was a vulnerability where attackers took the published algorithm
for valid account numbers and attacked using account numbers that
satisfied the published algorithm. somewhat as a result, guite some
time agao, the CVV field was added to the magstripe ... which could be
considered a kind of one-way hash of the contents of the magstripe ...
with some other stuff that is not predictable from the algorithm (as a
countermeasure to attacks from automatically generated account
numbers).
one of the "business processes" is that somebody calls their issuing
bank and disputes a charge by a specific merchant on such & such a
date. the issuing bank eventually provides notice to the merchant
(giving the account number, date, and purchase details). the merchant
then looks for a transaction (in their transaction log) for that
account number on that date. In some cases, the merchant bank
processor may provide an online service for merchants ... where the
merchant processor keeps the online merchant transaction log on behalf
of merchants for things like dispute resolution (this may include
things like online library of digital images of the original
reciepts).
There was a least one processing specification (possibly even
mandatory) during the 90s ... where each transaction was giving a
unique transaction identifier ... and transaction logs were only to be
referenced by the transaction identifier. However, consumers only
identified their account number by their account number ... and so
processes, like dispute resolution, continued to use the account
number as the identifier (and you need something else to be used for
authentication ... since the use of the account number as the
identifier is so ingrained into so many processes ... including the
minds of the consumers).
however, with regard to the magstripe, there are lots of widely
published reports about magstripe being skimmed at point-of-sale
devices, at ATM machines (and/or the value of the magstripe being
skimmed in transit) ... and counterfeit magstripe/cards being produced
for fraudulent transactions.
here is a news article from yesterday about magstripe from
credit/debit cards being skimmed (including the CVV field) and used to
rewrite the magstripe on (magstripe) gift cards:
Gift Cards Carrying Cloned Data Used To Steal Gas
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1121867212622215212&block=
Online ID Thieves Exploit Lax ATM Security
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Online ID Thieves Exploit Lax ATM Security
Date: Wed, 03 Aug 2005 10:25:27 -0600
To: R.A. Hettinga <rah@xxxxxxxx>
CC: cryptography@xxxxxxxx
two-factor authentication nominal objective is to have different
vulnerabilities, i.e. PINs (something you know) is nominally
countermeasure to lost/stolen cards (something you have).
However, skimming exploits can copy both magstripe and pin for
producing a counterfeit magstripe card that can be used with stolen
PIN (common vulnerability) ... minor reference found with search
engine:
http://wiki.whatthehack.org/index.php/Time_to_Ditch_the_Magstripe
The phishing vulnerability can steal both account number and PIN for
producing counterfeit magstripe card for use with the stolen pin;
again, common vulnerability defeating objective of using two-factor
authentication.
back in the dark ages there were attacks on magstripe credit cards
that used the algorithms for valid account numbers to generate
counterfeit magstripe credit cards. magstripes then acquired
effectively a kind of hash code as countermeasure to counterfeit
mastripes with algorithm generated account numbers. this turns out to
also be a countermeasure for counterfeit magstripe credit cards that
have been created from phished account number (however this isn't a
countermeasure to skimmed magstripe exploit that produces counterfeit
magstripe with all the exact information). description of magstripe
(and descretionary data field) format:
http://en.wikipedia.org/wiki/Magnetic_stripe_card
PINs have also been used as countermeasure to counterfeit magstripe
debit cards ... possibly based on assumption that counterfeit debit
magstripe from phishing exploits were similar threat to lost/stolen
card. However, this isn't a effective countermeasure when both the PIN
and the account number (magstripe) have a common vulnerability
(phishing)
As an aside, a countermeasure for lost/stolen cards is also early
reporting (owner is aware of the missing card). However this is not
applicable to skimmed/phished information since the card owner might
not even be aware that it has happened (until after discovering
fraudulent transactions).
...
spate of recent articles on phishing and ATM/debit
Analysts Say ATM Systems Highly Vulnerable To Fraud
http://www.banktech.com/aml/showArticle.jhtml?articleID=167100238
Something Phishy's Going On
http://www.banktech.com/aml/showArticle.jhtml?articleID=167100396
E-Fraud | Cybercrooks Target ATM And Debit Cards, Steal Billions
http://www.techweb.com/wire/security/167100202
Analysts Say ATM Systems Highly Vulnerable To Fraud
http://www.financetech.com/utils/www.banktech.com/story/enews/showArticle.jhtml?articleID=167100238
Phishers exploiting lax ATM security - Gartner
http://www.finextra.com/fullstory.asp?id=14058
Banks let phishers get away with $2.75bn
http://www.vnunet.com/vnunet/news/2140690/banks-let-phishers-away-75b
Banks let phishers get away with $2.75bn
http://www.pcw.co.uk/vnunet/news/2140690/banks-let-phishers-away-75b
Phishing attacks highlight banks' weaknesses
http://news.zdnet.co.uk/internet/security/0,39020375,39211852,00.htm
Phishers cash in on ATM cards
http://www.zdnetasia.com/news/security/0,39044215,39246973,00.htm
ATM Systems Highly Vulnerable
http://www.newsfactor.com/story.xhtml?story_id=003000002F1U
[Clips] Escaping Password Purgatory
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Clips] Escaping Password Purgatory
Date: Fri, 05 Aug 2005 14:24:59 -0600
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
CC: Bill Frantz <frantz@xxxxxxxx>, cryptography@xxxxxxxx
Jerrold Leichter wrote:
Hmm. I came up with the same idea a while back - though with a
different constraint: I think it's reasonable to trade off the
one-wayness of the hash for the ability to work out the password with
pencil and paper when necessary. Various classic pencil-and-paper
encryption systems can be bent to this purpose. Since the volume of
data "encrypted" is very small and it's hard for an attacker to get
his hands on more than tiny samples - a given web site only sees its
own password - you don't need much strength to give a reasonable
degree of protection.
note that rfc2289 is one time password
http://www.garlic.com/~lynn/rfcidx7.htm#2289
... takes passphrase, a site supplied salt, and iterative hashing.
supposedly this was to allow transmission in the clear and resistance
to man-in-the-middle attacks. the idea was also that the person only
had to remember a single passphrase
however, the following discusses a man-in-the-middle exploit ...
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#46 What 'NSA'?
http://www.garlic.com/~lynn/2003p.html#10 Secure web logins w random passwords
Cross logins
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Cross logins
Date: Fri, 05 Aug 2005 14:37:29 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
Is it possible for two web sites to arrange for cross
logins?
The goal is that if someone is logged into website
https://A.com as user127, and then browses to
https://B.com/A_com_registrants, he will be
automatically logged in on b.com as user127@A.com
project athena was being funded to the tune of $50m split between dec
and ibm. my wife and I got to go by periodically and review their
projects. on one of the visits we were on the leading edge of working
out the details of kerberos cross-domain operation.
in the following years ... it turns out that the protocol wasn't the
big issue ... it was establishing the business trust between two
independent organizations (not the protocol issues) ... random past
kerberos posts
http://www.garlic.com/~lynn/subpubkey.html#kerberos
however, maybe two years ago, i saw a presentation on a saml
cross-domain deployment ... that went into some details on the message
flows. I happened to observe that the basic message flows looked
exactly like the kerberos cross-domain message flows (dating back to
start of kerberos cross-domain). first, the person doing the
presentation was surprised that anybody in the audience had ever heard
of kerberos ... and then they finally allowed that there might just
be a limited number of ways of doing cross-domain operation.
saml reference:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
[Clips] Does Phil Zimmermann need a clue on VoIP?
From: Anne & Lynn Wheeler <lynn@xxxxxxx
Subject: Re: [Clips] Does Phil Zimmermann need a clue on VoIP?
Date: Sat, 06 Aug 2005 09:18:14 -0600
To: mxe20@xxxxxxx
CC: cryptography@xxxxxxxx
Mark Allen Earnest wrote:
*yawn* Yet another person who confuses PK with PKI. Almost NOBODY has
ever done PKI right. The I is the part everyone conveniently forgets
when they claim otherwise.
when we were doing this stuff related to e-commerce ... we also had to
go out and audit some number of these certificate issuing
institutions. we frequently explained to them what a service
operation was. at the time, we coined the term certificate
manufacturing to help differentiate from a PKI. one of the largest
organization commented that they originally thot it somehow involved
computers and technology and other fancy stuff ... and they were
finding out that even simple certificate manufacturing was 95
percent or more bookkeeping, accounting and paper work. there were
frequently questions about how they might outsource even that little
part of service oriented operation.
random past posts on ssl domain name certificates ... some number dating
back to the period of the original payment gateway.
http://www.garlic.com/~lynn/subpubkey.html#sslcert
one of the big issues for real businesses with extensive and well
established relationship management infrastructure ... it readily
became apparent that even trivial certificate manufacturing
operation represented a significant redundant and superfluous activity
... unnecessarily duplicating existing business operations.
[Clips] Does Phil Zimmermann need a clue on VoIP?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Clips] Does Phil Zimmermann need a clue on VoIP?
Date: Sat, 06 Aug 2005 15:18:19 -0600
To: cryptography@xxxxxxxx
CC: mxe20@xxxxxxxx
Anne & Lynn Wheeler wrote:
random past posts on ssl domain name certificates ... some number dating
back to the period of the original payment gateway.
http://www.garlic.com/~lynn/subpubkey.html#sslcert
oops, finger slip, that should be
http://www.garlic.com/~lynn/subpubkey.html#sslcert
... oh, and there are some slightly related postings regarding the
period from another thread:
http://www.garlic.com/~lynn/2005n.html#30 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#28 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits
solving the wrong problem
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: solving the wrong problem
Date: Tue, 09 Aug 2005 13:08:42 -0600
To: John Denker <jsd@xxxxxxxx>
CC: Adam Shostack <adam@xxxxxxxx>,
cryptography@xxxxxxxx, perry@xxxxxxxx
John Denker wrote:
That's an interesting topic for discussion, but I don't think
it answers Perry's original question, because there are plenty
of situations where the semblence of protection is actually a
cost-effective form of security. It's an example of statistical
deterrence.
i've frequently used a metaphor about a bank vault door installed in the
middle of an open field.
http://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/2002l.html#12 IEEE article on intelligence and security
http://www.garlic.com/~lynn/2003h.html#26 HELP, Vulnerability in Debit PIN Encryption security, possibly
http://www.garlic.com/~lynn/2003n.html#10 Cracking SSL
the other metaphor is the one about if all you have is a hammer, then
all problems become nails.
and for some of the PKI related ... frequently they start out claiming
the answer is PKI ... before asking what the problem is.
one of the current issues is that some financial operations are using
a value for a userid-like capability and at the same time using the
same value as a password-like capability. userid requires fairly high
security integrity ... aka from PAIN
- privacy
- authentication
- integrity
- non-repudiation
and the userid capability also requires fairly general availability in
order to establish permissions and as the basis for other business
operations.
however, the password capability requires very high privacy and
confidentiality. the result is relatively high diametrically opposing
use critiaria ... high integrity and generally available ... vis-a-vis
high confidentiality.
pure encryption might claim that they could meet the high
confidentialilty requirements ... but that then tends to break all the
"generally available" requirements for its userid function (and/or
esposing it in the clear for all its business use operations creates
enormous number of points for the value to leak out)
the fundamental threat model then turns out not to be there isn't enuf
encryption ... the fundamental threat model is a dual-use vulnerability
... where the same information is being used to select permissions
(aka userid) and needs to be generally available ... while at the same
time serving as a password (for authentication).
How much for a DoD X.509 certificate?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How much for a DoD X.509 certificate?
Date: Thu, 11 Aug 2005 12:55:48 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx
Peter Gutmann wrote:
$25 and a bit of marijuana, apparently. See:
http://www.wjla.com/news/stories/0305/210558.html
http://www.wjla.com/news/stories/0105/200474.html
Although the story doesn't mention this, the "ID" in question was
the DoD Common Access Card, a smart card containing a DoD-issued
certificate. To get a CAC, you normally have to provide two forms
of verification... in this case I guess the two were photo ID of
dead presidents and empirical proof that you know how to buy weed.
The cards were issued by Yusuf Khalil Jackson, a man with a long
criminal history (including, ironically, identity fraud):
one might claim that part of this is the lingering affinity to offline
credentials ... when most really secure operations have gone to online
and realtime operations ... leaving any physical object primarily a
feature of something you have authentication that might be used in
conjunction with other authentication factors.
the issue of many offline credentials are that they are left over from
a bygone era that is rapidly disappearing, but some of the legacy
mindsets still linger on.
the issue was raised in the mid-90s in financial infrastructures ...
that such offline credentials ... even tho redundant and superfluous
(in a modern online world) wouldn't actually be hurting anything
(other than possibly the out-of-pocket expense to support such
operations).
the danger did show up when operations were tempted to use the
redundant and superfluous credential in lieu of doing an actual online
operation.
How much for a DoD X.509 certificate?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How much for a DoD X.509 certificate?
Date: Fri, 12 Aug 2005 10:43:20 -0600
To: John Saylor <johns@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>, cryptography@xxxxxxxx
John Saylor wrote:
as i understand it, the problem here was that credentials were issued
by an untrustworthy agent. you can have this scenario both online and
off. how does being online solve the problem of a compromised issuing
authority?
the justification for having offline credentials typically has been
because 1) the technology isn't available for doing an online
infrastructure for accessing the real data or 2) the value of the
operation doesn't justify the cost & expense of having a real online
infrastructure.
the statement was that most modern day infrastructures have gone to
real online operations where the real information is accessed rather
than substitute offline credential .... this transition has been
- the online technology to access the real information is becoming
more ubiquitous,
- the cost of doing online access to the real information has been
dropping,
- many of the security sensitive infrastructures realize that they
now can easily justify any incremental expense of full online
operation (including the additional benefits of being able to analyze
activity across multiple sequences of security related events
... rather than each individual security event occuring in offline
isolation purely based on the contents of the offline credential).
I've frequently explained the analogy that offline credentials are
basically a read-only cache of the real information stored in a
repository some place. they are a direct analogy (modulo possibly the
read-only characteristics) of distributed cpu cache/memory,
distributed databases, ... any kind of distributed operation where
specific activities go on referencing in isolation the local read-only
copy.
so if you physically compare direct access operation to the real
information (including the ability to have a global view of operations
across individual events and be able to re-act and correct in real
time) ... vis-a-vis offline, isolated, distributed operation involving
the copies .... there are a significantly larger number of places that
directly touch the distributed read-only copies which can possibly
result undetected corruption (compared to direct accesses to the real
information).
it isn't that there aren't touch points that can corrupt the real
information ... it is just that there possibly are several orders of
magnitude fewer touch points that can corrupt the real information.
in a PKI, certification authority operations ...
- the "real information" is the authoritative agency responsible for
the actual information.
- typically a certification authority then will create its own
repository operation duplicating the real information
- it creates a certificate containing some subset of the real
information which is relatively freely released into the widld
the issue is that in the real respository #1 and possibly any
certification authority's shadow #2, the possible value of criminal
corruption of the real information is a lot higher ... but there tends
to be significantly larger number of security countermeasures against
there being any sort of corruption.
the individual certificate copies released into the wild tends to have
much fewer countermeasures and a much large number of infrastructure
attack points. in the case of the original ... the information is
either correct or it is not correct. in the offline credential copy
... the offline credential copy can 1) be a copy of incorrect
information (from the original) or 2) possibly be one of many
counterfeit copies containing fraudulent information.
so the online infrastructure is not concerned about there being
counterfeit copies of the information or ficticious counterfeits (of
information that doesn't even exist at the original) ... because
copies don't exist.
online infrastructure, however is concerned about valid authentication
and the counterfeiting of valid authentication information. i contend
that this is a much narrower exposure than the exposure of having
generalized counterfeit information floating around random locations in
the infrastructure. furthermore, the online infrastructure has much
greater capability for tracking and potentially recognizing counterfeit
authentication operation and furthermore, being able to react to it in
real time.
So somewhat after I was making statements about online infrastructure
having much fewer and narrower corruption points, having more
capability for recognizing compromises (being able to analyze patterns
across multiple security related events) and doing real-time re-acting
... there started appearing things like OCSP.
However, i claim that if you can do an a real-time, online operation
... you are incurring the majority of the expense of doing a
real-time, online operation ... and therefor you would have much
higher integrity simply transitioning to a real-time, online operation
... and eliminate the offline information that is floating around out
in the wild.
slightly related recent posting regarding sanity check about whether
you have a fundamental online system or a fundamental offline system
... and if you have a fundamental online system ... then it is trivial
to show that digital certificates are redundant and superfluous in a
fundamental online system, and if you can show digital certificates
are redundant and superfluous in a fundamental online system ... then
you can also show that certification authorities and PKI are also
redundant and superfluous.
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline situation
http://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for offline situation
aka ... fundamentally digital certificates were designed to
specifically address the offline situation. frequently the use of
digital certificates in online situations are contrived and results in
being able to trivially show that they are redundant and superfluous.
The summer of PKI love
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The summer of PKI love
Date: Fri, 12 Aug 2005 15:09:51 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
PKI's deployment to identify ssl servers is near one
hundred percent. PKI's deployment to sign and secure
email, and to identify users, is near zero and seems
unlikely to change. PGP has substantially superior
penetration.
PKI deployment to authenticate SSL servers almost doesn't exist.
we were called in to work with this small client/server startup that
wanted to do payments on their server ... and had this technology
called SSL. we had to do a lot of laying out the business ground work
for the payment stuff ... and because they wanted to use SSL for
pieces of it and certification authorities issuing digital
certificates were involved ... we also had to go audit the major
digital certificate issuing institutions.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
in the course of doing this ... we coined the term certificate
manufacturing to describe what we were finding ... as one way of
differentiating it from the industry accepted definition for PKI.
http://www.garlic.com/~lynn/subpubkey.html#sslcert
another place that it came up ... was that we had a SSL encrypted
session defined between webservers (doing payment transactions) and
the payment gateway. special digital certificates were issued for both
the webservers and the payment gateway as part of initializing the
encrypted tunnel (and we forced the implementation of mutual
authentication ... rather than the simple one-way that was available
at the time). At this point it became readily apparent that the
digital certificates part of all this were redundant and
superfluous. All the webservers had the public key of the payment
gateway pre-installed in the webserver ... and the payment gateway had
a separate mechanism (once the encrypted tunnel was set up) for
authenticating the webserver (based on established payment processing
conventions). while there was movement of digital certificates during
the setup of this encrypted tunnel ... it was purely an artificial
artifact of the existing code implementation and didn't actually serve
any other useful purpose.
this then resulted in re-examing the design-point and requirements for
digital certificates, certification authorities, and PKI ... which was
to address an introduction issue where a relying party was facing
first time communication with a total stranger and had no access to
any other means for obtaining information (aka the letters of credit
model from the sailing ship days). In situations where there was an
established relationship between the two parties ... it was fairly
trivial to demonstrate that the digital certificates were redundant
and superfluous.
so the original justification for server domain name digital
certificates in SSL was
- key exchange ... which can be done via other mechanism
- address perceived integrity issues with the domain name
infrastructure so that the user has some level of confidence that the
server they think they are talking to actually is the server they are
talking to.
basically, the browser checks