Re: "SSL stops credit card sniffing" is a correlation/causality myth

2005-05-31 Thread Perry E. Metzger

Ian G <[EMAIL PROTECTED]> writes:
>> Perhaps you are unaware of it because no one has chosen to make you
>> aware of it. However, sniffing is used quite frequently in cases where
>> information is not properly protected. I've personally dealt with
>> several such situations.
>
> This leads to a big issue.  If there are no reliable reports,
> what are we to believe in?  Are we to believe that the
> problem doesn't exist because there is no scientific data,
> or are we to believe those that say "I assure you it is a
> big problem?"
[...]
> The only way we can overcome this issue is data.

You aren't going to get it. The companies that get victimized have a
very strong incentive not to share incident information very
widely. However, those of us who actually make our living in the field
generally have a pretty strong sense of what is going wrong out there.

> It can't be the latter;  not because I don't believe you in
> particular, but because the industry as a whole has not
> the credibility to make such a statement.  Everyone who
> makes such a statement is likely to be selling some
> service designed to benefit from that statement, which
> makes it very difficult to simply believe on the face of it.

Those who work as consultants to large organizations, or as internal
security personnel at them, tend to be fairly independent of particular
vendors. I don't have any financial reason to recommend particular
firms over others, and customers generally are in a position to judge
for themselves whether what gets recommended is a good idea or not.

> If you have seen such situations, document them and report them - on
> forums like these.  Anonymise them suitably if you have to.

Many of us actually take our contract obligations not to talk about
our customers quite seriously, and in any case, anonymous anecdotal
reports about unnamed organizations aren't really "data" in the
traditional sense. You worry about vendors spreading FUD -- well, why
do you assume you can trust anonymous comments not to be FUD from
vendors?

You don't really need to hear much from me or others on this sort of
thing, though. Pretty much common sense and reasoning will tell you
things like "the bad guys attack the weak points" etc. Experience says
if you leave a vulnerability, it will be exploited eventually, so you
try not to leave any.

All the data in the world isn't going to help you anyway. We're not
talking about what percentage of patients with melanoma respond
positively to what drug. Melanomas aren't intelligent and don't change
strategy based on what other melanomas are doing. Attack strategies
change. Attackers actively alter their behavior to match conditions.

The way real security professionals have to work is analysis and
conservatism. We assume we're dumb, we assume we'll make mistakes, we
try to put in as many checks as possible to prevent single points of
failure from causing trouble. We assume machines will be broken in to
and try to minimize the impact of that. We assume some employees will
turn bad at some point and try to have things work anyway in spite of
that.

> Another way of looking at this is to look at Choicepoint.
> For years, we all suspected that the real problem was
> the insider / node problem.  The company was where
> the leaks occurred, traditionally.
>
> But nobody had any data.  Until Choicepoint.  Now we
> have data.

No you don't.

1) You have one anecdote. You really have no idea how
   frequently this happens, etc. 
2) It doesn't matter how frequently it happens, because no two
   companies are identical. You can't run 100 choicepoints and see
   what percentage have problems.
3) If you're deciding on how to set up your firm's security, you can't
   say "95% of the time no one attacks you so we won't bother", for
   the same reason that you can't say "if I drive my car while
   slightly drunk 95% of the time I'll arrive safe", because the 95%
   of the time that nothing happens doesn't matter if the cost of the
   5% is so painful (like, say, death) that you can't recover from
   it. In particular, you don't want to be someone on who's watch a
   major breech happens. Your career is over even if it never happens
   to anyone else in the industry.
3) Most of what you have to worry about is obvious anyway. There's
   nothing really new here. We've understood that people were the main
   problem in security systems since before computer security. Ever
   wonder why accounting controls are set up the way they are? How
   long were people separating the various roles in an accounting
   system to prevent internal collusion? That goes back long before
   computers.

> So we need to see a "Choicepoint" for listening and sniffing and so
> forth.

No, we really don't.

> And we need that before we can consider the listening threat to be
> economically validated.

Spoken like someone who hasn't actually worked inside the field.

Statistics and the sort of economic analysis you speak of depends on
assumpti

Re: Citibank discloses private information to improve security

2005-05-31 Thread Anne & Lynn Wheeler

Ed Gerck wrote:
Also, in an effort to make their certs more valuable, CAs have made 
digitally
signed messages imply too much -- much more than they warrant or can 
even represent.
There are now all sorts of legal implications tied to PKI signatures, in 
my opinion

largely exagerated and casuistic.


as discussed in numerous non-repudiation posts, dual-use threat posts, 
and posts about human signatures  where the human signature implies 
that the person has read, understood, authorizes, approves, and/or 
agrees with what is read and understood .,...


the validation of a digital signature with a public key implies that the 
message hasn't been altered since transmission and there is "something 
you have" authentication (the originator has access and use of the 
corresponding private key). the simple validation of a digital signature 
doesn't carry with it any of the sense of a human signature and/or 
non-repudiation.


in most business scenarios ... the relying party has previous knowledge 
and contact with the entity that they are dealing with (making the 
introduction of PKI digital certificates redundant and superfluous). 
Furthermore, x.509 identity certificates possibly horribly overloaded 
with personal information would reprensent significant privacy issues.


i've claimed that in the aads effort
http://www.garlic.com/~lynn/index.html#aads

not having to be pre-occupied with trying to interest relying parties in 
digital certificates containing information they already had  we 
were more free to concentrate on general threat, risk and vulnerability 
analysis. for instance, one of the things that a relying party might be 
really interested in is the integrity of the environment housing a 
subject's private key (is it in a software file or a hardware token, if 
a hardware token, what are the characteristics of the hardware token, 
etc) and the integrity of the environment in which a digital signature 
was generated.


one possible scenario is that CAs wanted to convince relying parties in 
the value of the certificates and not distract them with fundamental 
business integrity issues ... which might have resulted in businesses 
diverting money to fundamental business integrity items ... rather than 
spending on redundant and superfluous digital certificates likely 
containing information that they already had (i.e. having digital 
certificates would result in magical fu-fu dust being sprinkled over the 
rest of the infrastructure automagically precluding any such integrity 
problems?). furthermore they could spread semantic confusion ... somehow 
implying that because the term "digital signature" contained the word 
"signature" ... it was somehow related to a human signature.


lots of collected past postings related to fraud, exploits. 
vulernabilities, etc

http://www.garlic.com/~lynn/subpubkey.html#fraud

some number of posts on account number harvesting
http://www.garlic.com/~lynn/subpubkey.html#harvest

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: "SSL stops credit card sniffing" is a correlation/causality myth

2005-05-31 Thread Ian G
On Tuesday 31 May 2005 21:03, Perry E. Metzger wrote:
> Ian G <[EMAIL PROTECTED]> writes:
> > On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
> >> The next part of this is circular reasoning.  We don't see network
> >> sniffing for credit card numbers *because* we have SSL.
> >
> > I think you meant to write that James' reasoning is
> > circular, but strangely, your reasoning is at least as
> > unfounded - correlation not causality.  And I think
> > the evidence is pretty much against any causality,
> > although this will be something that is hard to show,
> > in the absence.
> >
> >  * AFAICS, a non-trivial proportion of credit
> > card traffic occurs over totally unprotected
> > traffic, and that has never been sniffed as far as
> > anyone has ever reported.
>
> Perhaps you are unaware of it because no one has chosen to make you
> aware of it. However, sniffing is used quite frequently in cases where
> information is not properly protected. I've personally dealt with
> several such situations.


This leads to a big issue.  If there are no reliable reports,
what are we to believe in?  Are we to believe that the
problem doesn't exist because there is no scientific data,
or are we to believe those that say "I assure you it is a
big problem?"

It can't be the latter;  not because I don't believe you in
particular, but because the industry as a whole has not
the credibility to make such a statement.  Everyone who
makes such a statement is likely to be selling some
service designed to benefit from that statement, which
makes it very difficult to simply believe on the face of it.

The only way we can overcome this issue is data.  If
you have seen such situations, document them and
report them - on forums like these.  Anonymise them
suitably if you have to.

Another way of looking at this is to look at Choicepoint.
For years, we all suspected that the real problem was
the insider / node problem.  The company was where
the leaks occurred, traditionally.

But nobody had any data.  Until Choicepoint.  Now we
have data.  We know how big a problem the node is.
We now know that the problem inside the company is
massive.

So we need to see a "Choicepoint" for listening and
sniffing and so forth.  And we need that before we can
consider the listening threat to be economically validated.


> Bluntly, it is obvious that SSL has been very successful in thwarting
> certain kinds of interception attacks. I would expect that without it,
> we'd see mass harvesting of credit card numbers at particularly
> vulnerable parts of the network, such as in front of important
> merchants. The fact that phishing and other attacks designed to force
> people to disgorge authentication information has become popular is a
> tribute to the fact that sniffing is not practical.

And I'd expect to see massive email scanning by
now of say lawyer's email at ISPs.  But, no, very
little has occurred.

> The bogus PKI infrastructure that SSL generally plugs in to is, of
> course, a serious problem. Phishing attacks, pharming attacks and
> other such stuff would be much harder if SSL weren't mostly used with
> an unworkable fake PKI. (Indeed, I'd argue that PKI as envisioned is
> unworkable.)  However, that doesn't make SSL any sort of failure -- it
> has been an amazing success.

In this we agree.  Indeed, my thrust all along in
"attacking PKI" has been to get people to realise
that the PKI doesn't do nearly as much as people
think, and therefore it is OK to consider improving
it.  Especially, where it is weak and where attackers
are attacking.

Unfortunately, PKI and SSL are considered to be
sacrosanct and perfect by the community.  As these
two things working together are what protects people
from phishing (site spoofing) fixing them requires
people to recognise that the PKI isn't doing the job.

The cryptography community especially should get
out there and tell developers and browser implementors
that the reason phishing is taking place is that the
browser security model is being bypassed, and that
some tweaks are needed.

> >  * We know that from our experiences
> > of the wireless 802.11 crypto - even though we've
> > got repeated breaks and the FBI even demonstrating
> > how to break it, and the majority of people don't even
> > bother to turn on the crypto, there remains practically
> > zero evidence that anyone is listening.
>
> Where do you get that idea? Break-ins to firms over their unprotected
> 802.11 networks are not infrequent occurrences. Perhaps you're unaware
> of whether anyone is listening in to your home network, but I suspect
> there is very little that is interesting to listen in to on your home
> network, so there is little incentive for anyone to break it.

Can you distinguish between break-ins and sniffing
and listening attacks?  Break-ins, sure, I've seen a
few cases of that.  In each case the hackers tried to
break into an unprotected site that was accessible
over an unprotected 802.11.

My point though is that th

Re: Citibank discloses private information to improve security

2005-05-31 Thread Anne & Lynn Wheeler

oops, sorry, forgot to include this one

Hong Kong banks to introduce two-factor authentication for online 
transactions

http://www.finextra.com/fullstory.asp?id=13744

Banks in Hong Kong are set to introduce two-factor authentication 
services to the country's 2.7 million Internet banking customers next month.


... snip ...

and lots of collected posts on 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Anne & Lynn Wheeler

just for the heck of it ... something today more from the physical world

ATM scams added to GASA’s fraud library
http://www.atmmarketplace.com/news_story_23307.htm

CAPE TOWN, South Africa and BROOKINGS, S.D. — The ATM Industry 
Association's Global ATM Security Alliance launched its online library 
of ATM fraud, according to a news release. The library is part of 
Cognito, GASA’s global ATM crime data management system.


... snip ...

... and
http://www.globalasa.com/

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Anne & Lynn Wheeler

Steven M. Bellovin wrote:
Bank of America is adopting some new schemes that might help.  First, 
they're asking users to select a picture the user selected at 
registration time.  The theory is presumably that a phishing site won't 
have the right image for you.  Second, you can "register" your 
computer; if your account is accessed from another computer, additional 
authentication is demanded, thus rendering a compromised password much 
less useful.


I think both schemes will help; I doubt that either will stop the 
problems.


a couple more

BofA rolls out authentication tools after data breach incident
http://eyeonit.itmanagersjournal.com/article.pl?sid=05/05/27/1816200
Bank of America looks to protect Online users with SiteKey
http://tech.monstersandcritics.com/news/article_1002765.php/Bank_of_America_looks_to_protect_Online_users_with_SiteKey
Payments News: Bank of America Launches SiteKey
http://www.paymentsnews.com/2005/05/bank_of_america.html
Bank of America | Sign up for the SiteKey Service
http://www.bankofamerica.com/privacy/passmark/
Bank of America takes on cyberscams
http://news.com.com/Bank+of+America+takes+on+cyberscams/2100-1029_3-5722035.html
Bank Of America Fights Phishing With New Authentication
http://informationweek.smallbizpipeline.com/news/163701500
Bank of America Announces Industry-Leading Security Feature ...
http://money.cnn.com/services/tickerheadlines/prn/200505261000PR_NEWS_USPR_CLTH009.htm
Bank of America's SiteKey scrutinized
http://news.com.com/2061-10789_3-5723556.html?part=rss&tag=5723556&subj=news

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Anne & Lynn Wheeler

Steven M. Bellovin wrote:
Bank of America is adopting some new schemes that might help.  First, 
they're asking users to select a picture the user selected at 
registration time.  The theory is presumably that a phishing site won't 
have the right image for you.  Second, you can "register" your 
computer; if your account is accessed from another computer, additional 
authentication is demanded, thus rendering a compromised password much 
less useful.


I think both schemes will help; I doubt that either will stop the 
problems.



http://www.bankofamerica.com/newsroom/press/press.cfm?PressID=press.20050526.03.htm


but they appear to be vulnerable to MITM-attacks

a recent thread
http://seclists.org/lists/fulldisclosure/2005/May/0629.html
http://seclists.org/lists/fulldisclosure/2005/May/0637.html
http://seclists.org/lists/fulldisclosure/2005/May/0639.html
http://seclists.org/lists/fulldisclosure/2005/May/0644.html

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Steven M. Bellovin
Bank of America is adopting some new schemes that might help.  First, 
they're asking users to select a picture the user selected at 
registration time.  The theory is presumably that a phishing site won't 
have the right image for you.  Second, you can "register" your 
computer; if your account is accessed from another computer, additional 
authentication is demanded, thus rendering a compromised password much 
less useful.

I think both schemes will help; I doubt that either will stop the 
problems.


http://www.bankofamerica.com/newsroom/press/press.cfm?PressID=press.20050526.03.htm

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: "SSL stops credit card sniffing" is a correlation/causality myth

2005-05-31 Thread Anne & Lynn Wheeler

Steven M. Bellovin wrote:
Given the prevalance of password sniffers as early as 1993, and given 
that credit card number sniffing is technically easier -- credit card 
numbers will tend to be in a single packet, and comprise a 
self-checking string, I stand by my statement.


the major exploits have involved data-at-rest ... not data-in-flight. 
internet credit card sniffing can be easier than password sniffing  
but that doesn't mean that the fraud cost/benefit ratio is better than 
harvesting large transaction database files. you could possibly 
conjecture password sniffing enabling compromise/exploits of 
data-at-rest ... quick in&out and may have months worth of transaction 
information all nicely organized.


to large extent SSL was used to show that internet/e-commerce wouldn't 
result in the theoritical sniffing making things worse (as opposed to 
addressing the major fraud vulnerability & treat).


internet/e-commerce did increase the threats & vulnerabilities to the 
transaction database files (data-at-rest) ... which is were the major 
threat has been. There has been a proliferation of internet merchants 
with electronic transaction database files ... where there may be 
various kinds of internet access to the databases. Even when the 
prevalent risk to these files has been from insiders ... the possibility 
of outsider compromise can still obfuscate tracking down who is actually 
responsible.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: "SSL stops credit card sniffing" is a correlation/causality myth

2005-05-31 Thread Perry E. Metzger

Ian G <[EMAIL PROTECTED]> writes:
> On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
>> The next part of this is circular reasoning.  We don't see network
>> sniffing for credit card numbers *because* we have SSL.
>
> I think you meant to write that James' reasoning is
> circular, but strangely, your reasoning is at least as
> unfounded - correlation not causality.  And I think
> the evidence is pretty much against any causality,
> although this will be something that is hard to show,
> in the absence.
>
>  * AFAICS, a non-trivial proportion of credit
> card traffic occurs over totally unprotected
> traffic, and that has never been sniffed as far as
> anyone has ever reported.

Perhaps you are unaware of it because no one has chosen to make you
aware of it. However, sniffing is used quite frequently in cases where
information is not properly protected. I've personally dealt with
several such situations.

Bluntly, it is obvious that SSL has been very successful in thwarting
certain kinds of interception attacks. I would expect that without it,
we'd see mass harvesting of credit card numbers at particularly
vulnerable parts of the network, such as in front of important
merchants. The fact that phishing and other attacks designed to force
people to disgorge authentication information has become popular is a
tribute to the fact that sniffing is not practical.

The bogus PKI infrastructure that SSL generally plugs in to is, of
course, a serious problem. Phishing attacks, pharming attacks and
other such stuff would be much harder if SSL weren't mostly used with
an unworkable fake PKI. (Indeed, I'd argue that PKI as envisioned is
unworkable.)  However, that doesn't make SSL any sort of failure -- it
has been an amazing success.

>  * We know that from our experiences
> of the wireless 802.11 crypto - even though we've
> got repeated breaks and the FBI even demonstrating
> how to break it, and the majority of people don't even
> bother to turn on the crypto, there remains practically
> zero evidence that anyone is listening.

Where do you get that idea? Break-ins to firms over their unprotected
802.11 networks are not infrequent occurrences. Perhaps you're unaware
of whether anyone is listening in to your home network, but I suspect
there is very little that is interesting to listen in to on your home
network, so there is little incentive for anyone to break it.

>> As for DNS hijacking -- that's what's behind "pharming" attacks.  In
>> other words, it's a real threat, too.
>
> Yes, that's being tried now too.  This is I suspect the
> one area where the SSL model correctly predicted
> a minor threat.  But from what I can tell, server-based
> DNS hijacking isn't that successful for the obvious
> reasons

You are wrong there again.

Where are you getting your information from? Whomever your informant
is, they're not giving you accurate information.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Anne & Lynn Wheeler

Adam Fields wrote:

Moreover, in my experience (as I've mentioned before on this list),
noticing an invalid certificate is absolutely useless if the banks
won't verify via another channel a) that it changed, b) what the new
value is or c) what the old value is.

I've tried. They won't/can't.


one might claim then that a solution is to go to a PGP-like repository 
of trusted public keys (in addition to and/or in conjunction of typical 
browser repostiory of trusted certification authority public keys). the 
URL & public key are loaded into the repository and some out-of-band 
process is used to establish the "trust" level of the information ... 
and you are involving the end-user in the trust establishment process.


For convenience ... enable this from bookmark and end-user clicks on 
trusted URLs. then rather than browser using webserver supplied 
certificate as part of SSL process, the browser uses the onfile trusted 
public key for that URL.

http://www.garlic.com/~lynn/subpubkey.html#certless

a threat is social-engineering can convince some number of naive users 
to do just about anything ... including things like updating a trusted 
public key repository ... and clicking on email obfuscated URLs (what 
the email claims to be the URL ... in unrelated to what the URL actually 
is). a major problem is that a large percentage of the population seems 
to be extremely naive about trust.


some large amount of the skimming and harvesting related fraud is 
because of existing authentication paradigms that make extensive use of 
static data and shared-secrets

http://www.garlic.com/~lynn/subpubkey.html#secrets

a countermeasure could be public key and digital signature verification 
based authentication. extensive use of file-based private keys make them 
vulnerable to harvesting by viruses ... but also vulnerable to social 
engineering attacks getting naive users to divulge contents of private 
key files.


a countermeasure might be hardware tokens where the private key can't be 
divulged ... even by the token owner. however, social engineering 
attacks can still get naive users to perform fraudulent transactions on 
behalf of crooks (even in hardware token based infrastructures). 
however, the percentage of the population vulnerabile to such attacks 
might go down as complexity of the social engineering and/or the 
awareness of the user population goes up.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Trojan horse attack involving many major Israeli companies, executives

2005-05-31 Thread J.A. Terranson

> John Saylor wrote:
> > hi
> >
> > ( 05.05.30 15:34 +0200 ) Amir Herzberg:
> >
> >>See more info e.g. at http://www.haaretz.com/hasen/spages/581790.html
> >
> >
> > an excellent tale [still unfolding]- no doubt coming to a bookstore or
> > movie theatre near you real soon.
> >
> > of course, it was never mentioned in the article, but they *had* to be
> > running windows.

So, how long before someone, possibly even me, points out that all
Checkpoint software is built in Israel?


-- 
Yours,

J.A. Terranson
[EMAIL PROTECTED]
0xBD4A95BF


"Never belong to any party, always oppose privileged classes and public
plunderers, never lack sympathy with the poor, always remain devoted to
the public welfare, never be satisfied with merely printing news, always
be drastically independent, never be afraid to attack wrong, whether by
predatory plutocracy or predatory poverty."

Joseph Pulitzer
1907 Speech

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: "SSL stops credit card sniffing" is a correlation/causality myth

2005-05-31 Thread Steven M. Bellovin
In message <[EMAIL PROTECTED]>, Ian G writes:
>On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
>> In message <[EMAIL PROTECTED]>, "James A. Donald" writes:
>> >--
>> >PKI was designed to defeat man in the middle attacks
>> >based on network sniffing, or DNS hijacking, which
>> >turned out to be less of a threat than expected.
>>
>> First, you mean "the Web PKI", not PKI in general.
>>
>> The next part of this is circular reasoning.  We don't see network
>> sniffing for credit card numbers *because* we have SSL.
>
>I think you meant to write that James' reasoning is
>circular, but strangely, your reasoning is at least as
>unfounded - correlation not causality.  And I think
>the evidence is pretty much against any causality,
>although this will be something that is hard to show,
>in the absence.

Given the prevalance of password sniffers as early as 1993, and given 
that credit card number sniffing is technically easier -- credit card 
numbers will tend to be in a single packet, and comprise a 
self-checking string, I stand by my statement.
>
> * AFAICS, a non-trivial proportion of credit
>card traffic occurs over totally unprotected
>traffic, and that has never been sniffed as far as
>anyone has ever reported.  (By this I mean lots of
>small merchants with MOTO accounts that don't
>bother to set up "proper" SSL servers.)

Given what a small percentage of ecommerce goes to those sites, I don't 
think it's really noticeable.
>
> * We know that from our experiences
>of the wireless 802.11 crypto - even though we've
>got repeated breaks and the FBI even demonstrating
>how to break it, and the majority of people don't even
>bother to turn on the crypto, there remains practically
>zero evidence that anyone is listening.
>
>  FBI tells you how to do it:
>  https://www.financialcryptography.com/mt/archives/000476.

Sure -- but setting up WEP is a nuisance.  SSL (mostly) just works.  As 
for your assertion that no one is listening, I'm not sure what kind of 
evidence you'd seek.  There's plenty of evidence that people abuse 
unprotected access points to gain connectivity.
>
>As an alternate hypothesis, credit cards are not
>sniffed and never will be sniffed simply because
>that is not economic.  If you can hack a database
>and lift 10,000++ credit card numbers, or simply
>buy the info from some insider, why would an
>attacker ever bother to try and sniff the wire to
>pick up one credit card number at a time?

Sure -- that's certainly the easy way to do it.
>
>And if they did, why would we care?  Better to
>let a stupid thief find a way to remove himself from
>a life of crime than to channel him into a really
>dangerous and expensive crime like phishing,
>box cracking, and purchasing identity info from
>insiders.
>
>> Since many of 
>> the worm-spread pieces of spyware incorporate sniffers, I'd say that
>> part of the threat model is correct.
>
>But this is totally incorrect!  The spyware installs on the
>users' machines, and thus does not need to sniff the
>wire.  The assumption of SSL is (as written up in Eric's
>fine book) that the wire is insecure and the node is
>secure, and if the node is insecure then we are sunk.

I meant precisely what I said and I stand by my statement.  I'm quite 
well aware of the difference between network sniffers and keystroke 
loggers.
>
>  Eric's book and "1.2 The Internet Threat Model"
>  http://iang.org/ssl/rescorla_1.html
>
>Presence of keyboard sniffing does not give us any
>evidence at all towards wire sniffing and only serves
>to further embarrass the SSL threat model.
>
>> As for DNS hijacking -- that's what's behind "pharming" attacks.  In
>> other words, it's a real threat, too.
>
>Yes, that's being tried now too.  This is I suspect the
>one area where the SSL model correctly predicted
>a minor threat.  But from what I can tell, server-based
>DNS hijacking isn't that successful for the obvious
>reasons (attacking the ISP to get to the user is a
>higher risk strategy than makes sense in phishing).

They're using cache contamination attacks, among other things.

...

>
>As perhaps further evidence of the black mark against
>so-called secure browsing, phishers still have not
>bothered to acquire control-of-domain certs for $30
>and use them to spoof websites over SSL.
>
>Now, that's either evidence that $30 is too much to
>pay, or that users just ignore the certs and padlocks
>so it is no big deal anyway.  Either way, a model
>that is bypassed so disparagingly without even a
>direct attack on the PKI is not exactly recommending
>itself.

I agre completely that virtually no one checks certificates (or even 
knows what they are).


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Lance James

Ed Gerck wrote:
Suppose you choose "A4RT" as your codeword. The codeword has no privacy 
concern
(it does not identify you) and is dynamic -- you can change it at will, 
if you

suspect someone else got it.

Compare with the other two identifiers that Citibank is using. Your full 
name
is private and static. The ATM's last-four is private and static too 
(unless

you want the burden to change your card often).



I agree on the privacy issue, your point is well taken there.


Lance James wrote:

But from your point, the codeword would be in the clear as well. 
Respectively speaking, I don't see how either solution would solve this.



Ed Gerck wrote:


List,

In an effort to stop phishing emails, Citibank is including in a 
plaintext
email the full name of the account holder and the last four digits of 
the

ATM card.







--
Best Regards,
Lance James
Secure Science Corporation
www.securescience.com
Author of 'Phishing Exposed'
http://www.securescience.net/amazon/
Have Phishers stolen your customers' logins? Find out with DIA
https://slam.securescience.com/signup.cgi - it's free!  


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: What happened with the session fixation bug?

2005-05-31 Thread Anne & Lynn Wheeler

James A. Donald wrote:

PKI was designed to defeat man in the middle attacks
based on network sniffing, or DNS hijacking, which
turned out to be less of a threat than expected.


asymmetric cryptography has a pair of keys ... the other of the key-pair 
decodes what has been encoding by one of them. a business process was 
defined using this technology where one of the key-pair is designated as 
public ... and freely distributed and the other of the key-pair is 
designated as confidential and never divulaged. an authentication 
business process was defined using public/private business process 
called digital signature  where a hash of a message is taken and 
encoded with the private key. the recipient can recompute the hash of 
the received message and compare it to the digital signature that has 
been decoded with the corresponding public key. this catches whether the 
message has been altered and from 3-factor authentication

http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

implies "something you have" authentication ... i.e. the originator has 
access and use of the corresponding private key.


PKI was somewhat targeted at the offline email model of the early 80s; 
the relying party dials up their (electronic) post office, exchanges 
email, and hangs up. They then may be dealing with first time 
correspondance from a total stranger with no (offline or online) 
recourse for determining information about the sender. Relying parties 
could be seeded with trusted public key repository of trusted third 
party certification authorities. Stangers could be issued "certificates" 
(digitally signed by one of these certification authorities) containing 
informoation about themselves bound to their public key. Email 
recipients in the offline email days of the early 80s ... could now of 
source of information regarding first time communication from total 
strangers (sort of the "letters of credit" model from the sailing ship 
days).


we were asked to work this small client/server startup in menlo park
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

that wanted to do payments on something they called a commerce server. 
In the year we worked with them ... they moved from menlo park to 
mountain view and changed their name (trivia question ... who previously 
had the rights to their new name? also what large corporate entity was 
providing most of the funding for the commerce sever?). some topic drift 
... recent postings referencing this original e-commerce work as an 
example of service oriented architecture (SOA):

http://www.garlic.com/~lynn/2005i.html#42
http://www.garlic.com/~lynn/2005i.html#43

they had this technology called SSL which was configured at addressing 
two issues: a) is the webserver that the user had indicated to the 
browser ... the actual webserver the browser was talking to and b) 
encryption of the transmitted information.


SSL digital certificates would be issued
http://www.garlic.com/~lynn/subpubkey.html#sslcert

which would contain the domain name of the webserver bound to their 
public key. the browsers would have trusted public key repository seeded 
with the public keys of some number of trusted third party certification 
authorities. the browser SSL process would compare the domain name 
indicated by the user to the domain name in the digital certificate 
(after validating the certificate).


(at least) two (other) kinds of vulnerabilities/exploits have shown up.

1) in the name of convenience, the browsers have significantly 
obfuscated the certificate operation from the end-user. attackers have 
devised ways for the end-users to indicate incorrect webservers ... 
which the browser SSL process (if it is even invoked) will then gladly 
validate as the webserver the user indicated.


2) a perceived issue (with knowing that the webserver that a browser is 
talking to is the webserver the user indicated) were integrity issues in 
the domain name infrastructure. however, as part of doing this 
consulting with this small client/server startup ... we also had to do 
detailed end-to-end business process due dilligence on some number of 
these certification authorities. it turns out that a certification 
authority typically has to check with the authoritative agency for the 
information they are certifying. the authoritative agency for domain 
name ownership is the domain name infrastructure ... the very 
institution that there are integrity questions giving rise to the 
requirement for SSL domain name server certificates.


In the second vulnerability, the certification authority industry is 
somewhat backing a proposal that when somebody registers a domain name 
with the domain name infrastructure ... they also register their public 
key. then in future communication with the domain name infrastructure, 
they digitally sign the communication. the domain name infrastructure 
the

"SSL stops credit card sniffing" is a correlation/causality myth

2005-05-31 Thread Ian G
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, "James A. Donald" writes:
> >--
> >PKI was designed to defeat man in the middle attacks
> >based on network sniffing, or DNS hijacking, which
> >turned out to be less of a threat than expected.
>
> First, you mean "the Web PKI", not PKI in general.
>
> The next part of this is circular reasoning.  We don't see network
> sniffing for credit card numbers *because* we have SSL.

I think you meant to write that James' reasoning is
circular, but strangely, your reasoning is at least as
unfounded - correlation not causality.  And I think
the evidence is pretty much against any causality,
although this will be something that is hard to show,
in the absence.

 * AFAICS, a non-trivial proportion of credit
card traffic occurs over totally unprotected
traffic, and that has never been sniffed as far as
anyone has ever reported.  (By this I mean lots of
small merchants with MOTO accounts that don't
bother to set up "proper" SSL servers.)

 * We know that from our experiences
of the wireless 802.11 crypto - even though we've
got repeated breaks and the FBI even demonstrating
how to break it, and the majority of people don't even
bother to turn on the crypto, there remains practically
zero evidence that anyone is listening.

  FBI tells you how to do it:
  https://www.financialcryptography.com/mt/archives/000476.html

As an alternate hypothesis, credit cards are not
sniffed and never will be sniffed simply because
that is not economic.  If you can hack a database
and lift 10,000++ credit card numbers, or simply
buy the info from some insider, why would an
attacker ever bother to try and sniff the wire to
pick up one credit card number at a time?

And if they did, why would we care?  Better to
let a stupid thief find a way to remove himself from
a life of crime than to channel him into a really
dangerous and expensive crime like phishing,
box cracking, and purchasing identity info from
insiders.

> Since many of 
> the worm-spread pieces of spyware incorporate sniffers, I'd say that
> part of the threat model is correct.

But this is totally incorrect!  The spyware installs on the
users' machines, and thus does not need to sniff the
wire.  The assumption of SSL is (as written up in Eric's
fine book) that the wire is insecure and the node is
secure, and if the node is insecure then we are sunk.

  Eric's book and "1.2 The Internet Threat Model"
  http://iang.org/ssl/rescorla_1.html

Presence of keyboard sniffing does not give us any
evidence at all towards wire sniffing and only serves
to further embarrass the SSL threat model.

> As for DNS hijacking -- that's what's behind "pharming" attacks.  In
> other words, it's a real threat, too.

Yes, that's being tried now too.  This is I suspect the
one area where the SSL model correctly predicted
a minor threat.  But from what I can tell, server-based
DNS hijacking isn't that successful for the obvious
reasons (attacking the ISP to get to the user is a
higher risk strategy than makes sense in phishing).

User node-based hijacking might be more successful.
Again, that's on the node, so it can totally bypass any
PKI based protections anyway.

I say "minor threat" because you have to look at the big
picture:  attackers have figured out a way to breach the
secure browsing model so well and so economically
that they now have lots and lots of investment money,
and are gradually working their way through the various
lesser ways of attacking secure browsing.

As perhaps further evidence of the black mark against
so-called secure browsing, phishers still have not
bothered to acquire control-of-domain certs for $30
and use them to spoof websites over SSL.

Now, that's either evidence that $30 is too much to
pay, or that users just ignore the certs and padlocks
so it is no big deal anyway.  Either way, a model
that is bypassed so disparagingly without even a
direct attack on the PKI is not exactly recommending
itself.

iang
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


RE: Citibank discloses private information to improve security

2005-05-31 Thread Peter Gutmann
"Heyman, Michael" <[EMAIL PROTECTED]> writes:

>In this situation, I believe that the users, through hard won experience with
>computers, _correctly_ assumed this was a false positive.

Probably not.  This issue was discussed at some length on the hcisec list,
(security usability, http://groups.yahoo.com/group/hcisec/), e.g:

-- Snip --

In my experience with helping out non-technical users, certificates are
treated as a purely boolean option, either they're valid or they're not.  In
fact usually the validity of certificates isn't even an option, either you get
a warning dialog or you don't, the actual text may as well be written in
Swahili.  People don't understand (or maybe don't want to understand) the
technical explanations that browsers throw up for them.  So an expired cert
would have the same status as one for the wrong site or a dozen other reasons
why the browser would throw up a warning.

I did some even less rigorous checking (i.e. asked a few users who were handy)
why they would have done something like this if they'd been one of the 300 and
their response was that since it was a known site that they'd dealt with
before, they'd assume it was some config error and continue anyway.  Several
of them had had similar problems with things like hotmail (that is, not SSL-
related but just general "it didn't work when I tried it" problems), where
clicking OK to get rid of warnings or waiting half an hour and trying again
had fixed things.  This was just another random site error that they would
have navigated around.

-- Snip --

For more discussion, see the list archives.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Victor Duchovni
On Tue, May 31, 2005 at 02:45:56PM +0100, Ian G wrote:

> On Saturday 28 May 2005 18:47, James A. Donald wrote:
> 
> > Do we have any comparable experience on SSH logins?
> > Existing SSH uses tend to be geek oriented, and do not
> > secure stuff that is under heavy attack.  Does anyone
> > have any examples of SSH securing something that was
> > valuable to the user, under attack, and then the key
> > changed without warning?  How then did the users react?
> 
> I've heard an anecdote on 2 out of 3 of those criteria:
> 
> In a bank that makes heavy use of SSH, the users have
> to phone the help desk to get the key reset when the
> warning pops up.  The users of course blame the tool.
> 
> I suspect in time the addition of certificate based
> checking into SSH or the centralised management
> of keys will overcome this.
> 

The solution for intramural use of SSH is to use Kerberos for mutual
authentication, this obviates the need for per-user known hosts files.

Though it took some time for the code that correctly integrates Kerberos
into OpenSSH to be adopted, AFAIK this is now done. If it is not (please
apply suitable prods to maintainers, as the code has been available for
some time).

The key obstacle was to allow Kerberos mutual auth to not only log the
user in, but to also authenticate the server despite any mismatch in the
(now ephemeral) RSA keys.

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Papers about "Algorithm hiding" ?

2005-05-31 Thread Ian G
On Thursday 26 May 2005 22:51, Hadmut Danisch wrote:
> Hi,
>
> you most probably have heard about the court case where the presence
> of encryption software on a computer was viewed as evidence of
> criminal intent.
>
> http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.htm
> http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-1030_
>3-5718978.html
>
>
>
> Plenty of research has been done about information hiding.
> But this special court case requires "algorithm hiding" as a kind of
> response. Do you know where to look for papers about this subject?
>
> What about designing an algorithm good for encryption which someone
> can not prove to be an encryption algorithm?

I don't agree with your conclusion that hiding algorithms
is a requirement.  I think there is a much better direction:
spread more algorithms.  If everyone is using crypto then
how can that be "relevant" to the case?

I would suggest that the best way to overcome this
flawed view of cryptography by the judges is to have
the operating systems install with GPG installed by
default.  Some of the better ones already install SSH
by default.

(In fact the thrust of the argument was flawed as the
user's PC almost certainly had a browser with SSL
installed.  As HTTPS can be used to access webmail
privately and as we have seen this was an El Qaeda
means of secret communication, the presence of one
more crypto tool as "relevent" is a stretch.)

iang
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Amir Herzberg


With bank web sites, experience has shown that only 0.3% 
of users are deterred by an invalid certificate, 
probably because very few users have any idea what a 
certificate authority is, what it does, or why they 
should care.  (And if you have seen the experts debating 
what a certificate authority is and what it certifies, 
chances are that those few who think they know are 
wrong)


Well, I have some usability tests that seem to prove your intuitive 
claim that most users don't know what's a CA. I don't know about 
arguments between experts on this. I think however that even naive users 
understand quite the TrustBar UI for SSL protected sites. We display 
something like  identified by . I'll 
 appreciate your thoughts/feedback, try it at http://TrustBar.MozDev.org.


--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com

New: see my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame.html


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Ian G
On Saturday 28 May 2005 18:47, James A. Donald wrote:

> Do we have any comparable experience on SSH logins?
> Existing SSH uses tend to be geek oriented, and do not
> secure stuff that is under heavy attack.  Does anyone
> have any examples of SSH securing something that was
> valuable to the user, under attack, and then the key
> changed without warning?  How then did the users react?

I've heard an anecdote on 2 out of 3 of those criteria:

In a bank that makes heavy use of SSH, the users have
to phone the help desk to get the key reset when the
warning pops up.  The users of course blame the tool.

I suspect in time the addition of certificate based
checking into SSH or the centralised management
of keys will overcome this.

iang
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Trojan horse attack involving many major Israeli companies, executives

2005-05-31 Thread Amir Herzberg
John, yes, I believe the Trojan ran on Windows. In fact, I just met my 
kids schoolmaster, and turns out she was also a victim of that person - 
already 3-4 years ago!!! Her daughter learned with his in the same 
school, and apparently he got mad at them and started abusing them in 
the most crazy ways - for instance, he intercepted family pictures sent 
to them, and _disfigured_the_pictures!! She went to the police but I 
guess was less lucky and they didn't find him, she changed computers, 
dial-up connection, etc. etc...


As you say - movie stuff. Amir

John Saylor wrote:

hi

( 05.05.30 15:34 +0200 ) Amir Herzberg:


See more info e.g. at http://www.haaretz.com/hasen/spages/581790.html



an excellent tale [still unfolding]- no doubt coming to a bookstore or
movie theatre near you real soon.

of course, it was never mentioned in the article, but they *had* to be
running windows.



--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com

New: see my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame.html


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Papers about "Algorithm hiding" ?

2005-05-31 Thread Jerrold Leichter
| Hi,
| 
| you most probably have heard about the court case where the presence
| of encryption software on a computer was viewed as evidence of
| criminal intent.
| 
| http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.htm
| 
http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-1030_3-5718978.html
| 
| 
| 
| Plenty of research has been done about information hiding.
| But this special court case requires "algorithm hiding" as a kind of
| response. Do you know where to look for papers about this subject?
There was a paper published on this a while back.  The question was posed as 
essentially:  Can one produce a "one-way trapdoor compiler"?  That is, just as 
an encryption algorithm takes plaintext and converts it to cryptotext, with 
the property that the inverse transformation is computationally intractable 
without the key, we want something that takes an algorithm and a key and 
produces a different but equivalent algorithm, such that asking some set of 
questions (like, perhaps, whether the output really *is* equivalent to the 
input) without the key is computationally intractable.  The result of the 
paper was that no such compiler can exist.
 
| What about designing an algorithm good for encryption which someone
| can not prove to be an encryption algorithm?
Can prove *any* algorithm is an "encryption algorithm"?  If so, I think there 
are some big prizes coming your way.

On a more general note:  This court case is being blown out of proportion. 
Screwdrivers, hammers, and a variety of other implements are "burglar's 
tools".  If you are caught in certain circumstances carrying burglar's tools, 
not only will they be introduced into evidence against you, but the fact you 
have them will be a criminal violation in and of itself.  The way the law 
deals with all kinds of ambiguities like this is to look at intent:  If I 
carry a screwdriver to repair a broken door on my own house, it's not a 
burglar's tool.  If I carry it to break the lock on my neighbor's house, it 
is.  Determining intent is up to a jury (or judge or judge's panel, depending 
on the legal system and the defendent's choices).  It's outside the realm of 
mathematics, proof in the mathematical sense, or much other than human 
judgement.  If an expert witness testifies something is an encryption 
algorithm, and the jury believes him more than the defense's expert witness 
who testifies it's a digital controller for a secret ice cream maker ... 
that's what it is.  If the jury further believes that encryption algorithm was 
used in the furtherance of a crime ... the defendent is in trouble.

-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


[EMAIL PROTECTED]: [IP] Intel quietly embeds DRM in it's 945 chips firmware]

2005-05-31 Thread Eugen Leitl
- Forwarded message from David Farber <[EMAIL PROTECTED]> -

From: David Farber <[EMAIL PROTECTED]>
Date: Tue, 31 May 2005 08:17:59 -0400
To: Ip ip 
Subject: [IP] Intel quietly embeds DRM in it's 945 chips firmware
X-Mailer: Apple Mail (2.730)
Reply-To: [EMAIL PROTECTED]



Begin forwarded message:

From:
Date: May 31, 2005 1:15:49 AM EDT
To: [EMAIL PROTECTED]
Subject: Re: [IP] Intel quietly embeds DRM in it's 945 chips firmware



Dave Farber:  Please remove my name and identity from this mailing,  
due to fear of reprisal. (I still work in the entetainment business  
from time to time.)

I do not know all about Intel's DRM, but I do know more, perhaps,  
than I should.  What I do know is that Intel has been working very  
closely with the entertainment industry on a DRM that, I've been  
told, seeks to satisfy EVERYONE'S wishes.  Of course, such a system  
would mean, by definition, that it will satisfy either no one, or  
only the studios.

But I do know that the Intel "dream" DRM system would allow content  
to be moved from one platform to another on a network, presumably  
through a check-in/check-out procedure, to make sure only a limited  
number of (legitimate) copies would be made and in service at any one  
time.  Intel's system also acknowledges, for example, that a high- 
resolution (e.g. high definition video) copy of a film could be used  
to create low-res (like Quicktime, Real or Windows Media) versions  
that could be used in portable video players.  Users might even be  
able to "loan" time-limited copies or be allowed to make a small  
number of copies, like Apple's Fair Play DRM permits.  You can check  
out Intel's ideas for such a system, and the participation of an   
entertainment and consumer electronics industry panel called the  
Digital Home Working Group, on which Intel sits, which has been  
addressing such a system in this article from February, 2004:

http://www.infoworld.com/article/04/02/24/HNbarrettdrm_1.html

(Note: The Japanese system for hard disk and DVD recorders that  
Barrett alludes to is called CPRM.  It is neither new nor flexible,  
and there has already been some consumer backlash against it in  
Japan, where it is used for the transmission of digital TV b'casts --  
sort of their "broadcast flag.")

At the root of the problem, of course, is the personal computer  
that's used as a media player platform.  This is also, not  
coincidentally, Intel's cash cow.  Such a DRM system, with the PC  
playing a pivotal role, would also mean that IBM or other chip  
vendors would not be allowed to play without building in the same  
chip-level protection.  Without these important security pieces,  
Apple, for example, would be cut out of the picture for playing  
content protected by the Intel-endorsed DRM, as would (most likely)  
Linux-based devices.

This is a GRAND PLAN that relies on it being either almost completely  
transparent to consumers (like Apple's Fair Play) or simple to  
understand.  Unfortunately, almost no DRM is easily understood by  
consumers.  Even most of the customer's for Apple's iTunes Music  
Store only become familiar with the terms under which they've  
purchased their music when they bump up against the limitations that  
have been set.

The real nightmare scenario, in my opinion, is a world in which  
several such DRMs co-exist, creating a chaotic environment in which  
you never know whether content will play on one plaform but not  
another.  This is a potentially really sticky mess.

-
You are subscribed as [EMAIL PROTECTED]
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature


RE: Citibank discloses private information to improve security

2005-05-31 Thread Heyman, Michael
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of James A. Donald
> Sent: Saturday, May 28, 2005 1:48 PM
> 
> With bank web sites, experience has shown that only 0.3% of 
> users are deterred by an invalid certificate, probably 
> because very few users have any idea what a certificate 
> authority is, what it does, or why they should care.
>
I assume you refer to the BankDirect case with the accidentally invalid
certificate.

In this situation, I believe that the users, through hard won experience
with computers, _correctly_ assumed this was a false positive. If an
attack had actually occurred, the users would have been wrong. Luckily
for them, they were correct and did not let the mistake interfere with
their commerce. The one in 300 users that did let the mistake interfere
wasted their time and, perhaps, money if they lost money due to the
delay in access.

As it stands, the system works reasonably well (of course it still has
its share of problems). If 300 out of 300 users wasted time and money
because of the mistake (say if the system were designed so users could
not bypass the possibly bad certificate warning), the security folks in
ivory towers may pat themselves on the back saying, "look, the system
works great!" - the actual users of the technology would be more then a
little ticked. A brittle system that cannot accept failures will always
have trouble dealing with us fallible types.

I'm not familiar with the BankDirect site, but if it like banking sites
I am used to, it is fairly impersonal and easy to spoof. One way to
reduce the ease-of-spoof factor is to add many ways to identify the bank
web site. If one or two of them fail, the web site is probably still
valid. Ways to identify a site include certificates, personalized
greetings ("Hello Michael, Welcome back, you haven't been here in 4 days
and we've missed you"), code words, the PetName tool, green light by
anti-phishing software, even the URL and overall look-and-feel. So what
if a couple of them fail? That happens all the time and we have to
expect that and design our systems to work in spite of it.

-Michael Heyman


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Papers about "Algorithm hiding" ?

2005-05-31 Thread Jozef Vyskoc
HD> What about designing an algorithm good for encryption which someone
HD> can not prove to be an encryption algorithm?

Hmmm, but to do that one needs to have a good definition of 'encryption
algorithm' and perhaps also some other apparently fundamental terms. But
we have none, I am afraid ... at least it seems it is hard to give precise
definition even of the cryptography alone (the old one relating that to
'secure communication over insecure channel' seems not to be consistent
with quantum crypto...)

Regards,

Jozef


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: Citibank discloses private information to improve security

2005-05-31 Thread Peter Gutmann
"James A. Donald" <[EMAIL PROTECTED]> writes:

>With bank web sites, experience has shown that only 0.3% of users are
>deterred by an invalid certificate, probably because very few users have any
>idea what a certificate authority is, what it does, or why they should care.

James (and others): I really wouldn't cite the BankDirect figure as a hard
value, since it represents just a single user, who may in turn have clicked on
the wrong button (i.e. the real figure could have been 0%).  It'd be better to
say "statistically insignificant" or "negligible" or some other close-to-or-
equal-to-zero synonym.

Peter.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


RE: Papers about "Algorithm hiding" ?

2005-05-31 Thread Valery Pryamikov
> -Original Message-
> Hadmut Danisch wrote:
> 
> ...
> Plenty of research has been done about information hiding.
> But this special court case requires "algorithm hiding" as a kind of
> response. Do you know where to look for papers about this subject?
> ...

Here is the list that you can start with:

[1] Boaz Barak, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit
Sahai, Sali Vadhan, Ke Yang. On the (im)possibility of obfuscating
programs. In Proceedings of CRYPTO 2001.
[2] Benjamin Lynn, Manoj Prabhakaran, Amit Sahai. Positive Results and
Techniques for Obfuscation. In Proceedings of Eurocrypt 2004. 
[3] Hoeteck Wee. On Obfuscating Point Functions. Computer Science
Division University of California, Berkeley. Jan 2005
[4] Christian Collberg, Clark Thomborson. Watermarking, tamper-proofing
and obfuscation - tools for software protection. IEEE Transactions on
software engineering, vol.28, No.8, August 2002.
[5] Christian Collberg, Clark Thomborson. Watermarking, tamper-proofing
and obfuscation - tools for software protection. Technical Report
TR00-03, The Department of Computer Science, University of Arizona,
February 2000.
[6] Christian Collberg, Clark Thomborson, Douglas Low. Breaking
Abstractions and Unstructuring Data Structures. IEEE International
Conference on Computer Languages, May 1998. 
[7] Christian Collberg, Clark Thoborson, Douglas Low. Manufacturing
Cheap, Resilient, and Stealthy Opaque Constructs. Principles of
Programming Languages 1998, POPL'98, January 1988.
[8] Christian Collberg, Clark Thomborson, Douglas Low. A Taxonomy of
Obfuscating Transformations. Technical Report 148, Department of
Computer Science, The University of Auckland. July 1997. 
[9] Chenxi Wang, Jonathan Hill, John Knight, Jack Davidson. Protection
of Software-based Survivability Mechanisms. International Conference of
Dependable Systems and Networks. July 2001. 
[10] Chenxi Wang. A Security Architecture for Survivability Mechanisms.
PhD Dissertation, Department of Computer Science, University of
Virginia, October 2000.
[11] Chenxi Wang, Jonathan Hill, John Knight, Jack Davidson. Software
Tamper Resistance: Obstructing Static Analysis of Programs. Technical
Report CS-2000-12, Department of Computer Science, University of
Virginia. May 2000.  
[12] Cullen Linn, Saumya Debray. Obfuscation of Executable Code to
Improve Resistance to Static Disassembly. ACM Conference on Computer and
Communications Security (CCS 2003), October 2003, pp. 290-299
[13] Fritz Hohl. A Framework to Protect Mobile Agents by Using Reference
States. Proceedings of the 20th International Conference on Distributed
Computing Systems (ICDCS 2000), pp. 410-417, 2000.
[14] Gregory Wroblewski. General Method of Program Code Obfuscation. PhD
Dissertation, Wroclaw. 2002.
[15] S. Chow, H. Johnson, P.C. van Oorschot, P Eisen. A White-Box DES
implementation for DRM applications. In Proceedings of ACM CCS-9
Workshop DRM. 2002
[16] Matthias Jacom, Dan Boneh, Edard Feltin. Attacking an obfuscated
cipher by injecting faults. In Proceedings of ACM CCS-9 Workshop DRM.
2002. 
[17] Yuval Ishai, Amit Sahai, David Wagner. Private Circuits: Securing
Hardware against Probing Attacks. In Proceedings of CRYPTO 2003.
[18] Markus Kuhn, Oliver Kommerling. Design Principles for
Tamper-Resistant Smartcard Processors. USENIX Workshop on Smartcard
Technology proceedings, Chicago, Illinois, USA, May 10-11, 1999.
[19] Ross Anderson, Markus Kuhn. Tamper resistance - a Cautionary Note.
The Second USENIX Workshop on Electronic Commerce Proceedings, Oakland ,
California, November 18-21 1996, pp 1-11.
[20] Gael Hachez. A Comparative Study of Software Protection Tools
Suited for E-Commerce with Contributions to Software Watermarking and
Smart Cards.
PhD thesis, Faculte des Sciences Appliquees Laboratoire de
Microelectronique. Universite Catholique de Louvain. March 2003.
[21] T.-C. Lin, M. Hsiang Hsu, F.-Y. Kuo, and P.-C. Sun. An Intention
Model-based Study of Software Piracy. In 32nd Annual Hawaii
International Conference on System Sciences (HICSS-32). IEEE Computer
Society, January 1999.
[22] Amit Sethi. Digital Rights Management and Code Obfuscation. Thesis
in fulfillment of degree of Master of Mathematics. University of
Waterloo, Ontario, Canada. 2003.
[23] M. Kunin. Why do Software Manufactures Tolerate Piracy in
Transition and Less Developed Countries? A theoretical model. Discussion
Paper Series 2001-75, JEL classification: O34;L20. Center for Economic
Research, Charles University and the Academy of Sciences, Czech
Republic, October 2001.
[24] Christian Collberg. SandMark Algorithms. January 28, 2003
[25] Christian Collberg, Ginger Myles, Michael Stepp. Cheating Cheating
Detectors. Department Computer Science University of Arizona. Technical
Report TR04-05. March 3, 2004
[26] James R. Gosler. Software Protection: Myth or Reality? Sandia
National Laboratory. Advances in Cryptology - CRYPTO'85. 1985.  
[27] Kelly Heffner, Christian Collberg. The Obfuscation Executive.

Re: Citibank discloses private information to improve security

2005-05-31 Thread Adam Fields
On Sat, May 28, 2005 at 10:47:56AM -0700, James A. Donald wrote:
[..]
> With bank web sites, experience has shown that only 0.3% 
> of users are deterred by an invalid certificate, 
> probably because very few users have any idea what a 
> certificate authority is, what it does, or why they 
> should care.  (And if you have seen the experts debating 
> what a certificate authority is and what it certifies, 
> chances are that those few who think they know are 
> wrong)

Moreover, in my experience (as I've mentioned before on this list),
noticing an invalid certificate is absolutely useless if the banks
won't verify via another channel a) that it changed, b) what the new
value is or c) what the old value is.

I've tried. They won't/can't.

> Do we have any comparable experience on SSH logins? 
> Existing SSH uses tend to be geek oriented, and do not 
> secure stuff that is under heavy attack.  Does anyone 
> have any examples of SSH securing something that was 
> valuable to the user, under attack, and then the key 
> changed without warning?  How then did the users react? 

Every time this has happened to someone I know who uses SSH, it's been
immediate cause for alarm, causing a phone call to the person who
administers the box asking "what the? did you reinstall the OS
again?".

-- 
- Adam

** I can fix your database problems: http://www.everylastounce.com/mysql.html **

Blog... [ http://www.aquick.org/blog ]
Links.. [ http://del.icio.us/fields ]
Photos. [ http://www.aquick.org/photoblog ]
Experience. [ http://www.adamfields.com/resume.html ]
Product Reviews: .. [ http://www.buyadam.com/blog ]


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: What happened with the session fixation bug?

2005-05-31 Thread Steven M. Bellovin
In message <[EMAIL PROTECTED]>, "James A. Donald" writes:
>--
>PKI was designed to defeat man in the middle attacks
>based on network sniffing, or DNS hijacking, which
>turned out to be less of a threat than expected.
>
First, you mean "the Web PKI", not PKI in general.

The next part of this is circular reasoning.  We don't see network 
sniffing for credit card numbers *because* we have SSL.  Since many of 
the worm-spread pieces of spyware incorporate sniffers, I'd say that 
part of the threat model is correct.

As for DNS hijacking -- that's what's behind "pharming" attacks.  In 
other words, it's a real threat, too.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


RE: Papers about "Algorithm hiding" ?

2005-05-31 Thread Scott Guthery
Isn't this what Rivest's "Chaffing and Winnowing" is all about?

http://theory.lcs.mit.edu/~rivest/chaffing.txt

Cheers, Scott

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hadmut Danisch
Sent: Thursday, May 26, 2005 5:51 PM
To: cryptography@metzdowd.com
Subject: Papers about "Algorithm hiding" ?

Hi,

you most probably have heard about the court case where the presence of
encryption software on a computer was viewed as evidence of criminal
intent.

http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.ht
m
http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-10
30_3-5718978.html



Plenty of research has been done about information hiding.
But this special court case requires "algorithm hiding" as a kind of
response. Do you know where to look for papers about this subject?

What about designing an algorithm good for encryption which someone can
not prove to be an encryption algorithm?


regards
Hadmut


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]