Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-28 Thread Bill Stewart
At 03:20 AM 7/18/2004, Enzo Michelangeli wrote:
Can someone explain me how the phishermen escape identification and
prosecution? Gaining online access to someone's account allows, at most,
to execute wire transfers to other bank accounts: but in these days
anonymous accounts are not exactly easy to get in any country, and anyway
any bank large enough to be part of the SWIFT network would cooperate in
the resolution of obviously criminal cases.
At least until a few years ago, and probably still today,
it was easy to get a non-anonymous account in the US using fake ID.
The Know Your Customer laws and other anti-terrorism fallout
may have encouraged banks to check SSNs a bit more carefully,
but as long as the person whose identity you're stealing
doesn't have horrendously bad or good credit,
it's probably still not hard.
If it costs you $100 in fake ID to get the account set up,
and you can burn the phish for $1000, then you win.
But credit cards are probably more common and certainly easier to use.
Buy laptops or other fungible goods, and sell them on eBay.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-25 Thread Peter Gutmann
Enzo Michelangeli [EMAIL PROTECTED] writes:

Can someone explain me how the phishermen escape identification and
prosecution? Gaining online access to someone's account allows, at most, to
execute wire transfers to other bank accounts:

Some (a lot of?) large-scale phishing is done by or with the aid of
international organised crime, who have a great deal of experience in making
money disappear (or reappear in cleaned form).  Even without that expertise,
there are many, many ways to launder the money.  One that I heard of recently
is to go to small in-debt businesses and offer to pay off their debt, with the
business then paying back half that in cash to the phisher.  The business has
half their debt paid off, and the phisher has converted their wire transfer
into untraceable cash.

Peter.

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


Re: RP -- Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-22 Thread Anne Lynn Wheeler
At 01:39 PM 7/21/2004, Ed Gerck wrote:
The PKI model is not tied to any legal jurisdiction and is not a
business process. What is meant then by relying-party (RP) and
RP Reliance in X.509 and PKIX? I hope the text below, from a
work in progress submitted as an IETF ID, helps clarify this issue.

the TTP (trusted third party) PKI business model typically described in the 
early 90s ... had a business exchange between a key owner and a 
certification authority ... where the key owner paid the certification 
authority for the issuing of a certificate that bound some information to 
the public key. The payment of money by the key owner to the certification 
authority created some sort of legal relationship between the key owner and 
the certification authority  with regard to the certificate.

in that environment  the key owner then digitally signed something, and 
sent the something with a digital signature and the certificate to a 
relying-party. The relying-party was frequently assumed to be making some 
sort of legal reliance and recourse on the performance of the certification 
authority. However, w/o payment of funds and/or other legal arrangement 
between the relying-party and the certification authority  there was no 
legal bases for reliance (unless mandated outside of traditional business 
context by some gov. mandate)

it appears that the GAO  working within that semantic  structural 
business context ... has taken some effort to create a legal basis for 
reliance and recourse between the relying parties and the certification 
authorities for the federal PKI . It basically has something along the 
lines of the certification authorities signing a contractual relationship 
with the GAO. Then all the relying parties also sign a contractual 
relationship with the GAO   then there is recourse for the relying 
parties on certification authority performance based on the relying parties 
contract with GAO (for certification authority performance) and the GAOs 
contract with the certification authorities (for certification authority 
performance). This is sort of trying to get around the lack of any implied 
performance and/or contractual relationship (and therefor recourse) because 
the relying parties haven't actually paid any money to the certification 
authorities.

In the simple case, having any sort of legal obligation between the 
certification authority and the key-owner ... and any sort of totally 
different legal obligation between the key-owner and a relying party ... 
normally would fail to create any sort of legal obligation between (the 
traditional TTP PKI) certification authorities (described in the early 90s) 
and the set of relying parties.

some of this became mute by the mid-90s with the observation that the 
traditionally considered identity x.509 certificates represented a 
significant privacy and liability exposure ... and the retrenching by 
infrastructures to relying-party-only certificates (effectively account 
number and public key ... although even a relying-party-only SET 
certificates could represent a factor of 100-times payload bloat). the 
other issue that quickly became observed if the relying-party and the 
certification authority were the same  then the relying party would 
typically have a large superset of the information that they included in 
any relying-party-only certificate ... and that having the key-owner to 
return this small subset of information repeatedly to the relying-party 
(/certification authority) was redundant and superfluous  other than 
possibly contributing huge computational and transmission overheads for no 
useful purpose.

IETF standards tend to be descriptions of protocol and parties role in the 
protocol. Such syntactical and semantical description of the protocols has 
rarely included description of any possible syntactical and semantic 
business relationships  especially of the typical kind being proposed 
in the early 90s for TTP certification authorities.

for pkix references  see
http://www.garlic.com/~lynn/rfcietff.htm
and click on Term (term-RFC#) in the RFC's listed by section
then click on PKI in the Acronym fastpath section.
the current results:
public key infrastructure (PKI)
see also file:///D:/users/http/rfcterms.htm#t508authentication , 
file:///D:/users/http/rfcterms.htm#t600encryption , 
file:///D:/users/http/rfcterms.htm#t770public key
file:///D:/users/http/rfcidx12.htm#38203820 
file:///D:/users/http/rfcidx12.htm#37793779 
file:///D:/users/http/rfcidx12.htm#37783778 
file:///D:/users/http/rfcidx12.htm#37703770 
file:///D:/users/http/rfcidx12.htm#37413741 
file:///D:/users/http/rfcidx12.htm#37393739 
file:///D:/users/http/rfcidx12.htm#37093709 
file:///D:/users/http/rfcidx12.htm#36533653 
file:///D:/users/http/rfcidx12.htm#36473647 
file:///D:/users/http/rfcidx11.htm#35623562 
file:///D:/users/http/rfcidx11.htm#34473447 
file:///D:/users/http/rfcidx11.htm#33793379 

Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-21 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Ian Grigg writes:

 
 Don't be silly. It's not a threat because people generally use
 SSL. Back in the old days, password capture was a very serious
 threat. It went away with SSH. It seems to me quite likely that
 it would be a problem with web browsing in the absence of SSL.


Right...  It's easy to claim that it went away
because we protected against it.  Unfortunately,
that's just a claim - there is no evidence of
that.

This is why I ask whether there has been any
evidence of MITMs, and listening attacks.  We
know for example that there were password
sniffing attacks back in the old days, by
hackers.  Hence SSH.  Costs - Solution.

But, there is precious little to suggest that
credit cards would be sniffed - I've heard one
isolated and unconfirmable case.  And, there is
similar levels of MITM evidence - anecdotes and
some experiences in other fields, as reported
here on this list.


I think that Eric is 100% correct here: it doesn't happen because it's 
a low-probability attack, because most sites do use SSL.

I think that people are forgetting just how serious the password 
capture attacks were in 1993-94.  The eavesdropping machines were on 
backbones of major ISPs; a *lot* of passwords were captured.  
Furthermore, the technology has improved -- have you looked at dsniff 
lately, with the ARP-based active attack capability?  And credit cards 
are much easier to grab -- they're probably sent in one packet, instead 
of several, and the number is a self-checking string of digits.

It's also worth remembering that an SSL-like solution -- cryptographically 
protecting the transmission of credit card number, instead of digitally 
signing a funds transfer authorization linked to some account -- was 
more or less the only thing possible at the time.  The Internet as a 
medium of commerce was too new for the banks to have developed 
something SET-like, and there wasn't an overwhelmingly-dominant client 
platform at the time for which custom software could be developed.  
(Remember that Windows 95 was the first version with an integral TCP/IP 
stack.)  *All* that Netscape could deploy was something that lived in 
just the browser and Web server.  SET itself failed because the 
incentives were never there -- consumers didn't perceive any benefit to 
installing funky software, and merchants weren't given much incentive 
to encourage it.

--Steve Bellovin, http://www.research.att.com/~smb


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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-21 Thread Ian Grigg
Steve,
thanks for addressing the issues with some actual
anecdotal evidence.  The conclusions still don't
hold, IMHO.
Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Ian Grigg writes:

Right...  It's easy to claim that it went away
because we protected against it.  Unfortunately,
that's just a claim - there is no evidence of
that.
This is why I ask whether there has been any
evidence of MITMs, and listening attacks.  We
know for example that there were password
sniffing attacks back in the old days, by
hackers.  Hence SSH.  Costs - Solution.
But, there is precious little to suggest that
credit cards would be sniffed - I've heard one
isolated and unconfirmable case.  And, there is
similar levels of MITM evidence - anecdotes and
some experiences in other fields, as reported
here on this list.

I think that Eric is 100% correct here: it doesn't happen because it's 
a low-probability attack, because most sites do use SSL.
The trick is to show cause and effect.  We know the
effect and we know the cause(s).  The question is, how
are they related?  The reason it is important is that
we may misapply one cause if the effect results from
some other cause.
I think that people are forgetting just how serious the password 
capture attacks were in 1993-94.  The eavesdropping machines were on 
backbones of major ISPs; a *lot* of passwords were captured. 
Which led to SSH, presumably, and was pre-credit card
days, so can only be used as a prediction of eavesdropping.
Question - are we facing a situation today whereby it is
easy to eavesdrop from the backbone of a major ISP and
capture a lot of traffic?  As far as I can see, that's
not likely to happen, but it could happen.
Secondly, who were the people doing those attacks?  Back
in 93-94, I'd postulate they weren't criminal types, but
hacker types.  That is, they were hackers looking for
machines.  Those people are still around - defeated by
SSH in large measure - and use other techniques now.
(Hackers had no liability in those days.  Criminals do
have liability, and are more concerned to cover their
tracks.  This makes active attacks less useful to them.
Criminals are getting braver though.)
Thirdly, why aren't we seeing more reports of this on
802.11b networks?  I've seen a few, but in each case,
the attack has been to hack into some machine.  I've
yet to see a case where listeners have scarfed up some
free email account passwords, although I suppose that
this must happen.
The point of all this is that we need to establish how
frequent and risky these things are.  Back in the pre-
commerce days, a certain amount of FUD was to be expected.
Now however, it's been a decade - whether that FUD was
warranted then is an issue for the historians, but now
we should be able to scientifically make a case that
the posture matches the threats.  Because it's been a
decade (almost).
As far as I can see, there *some* justification for
expecting eavesdropping attacks to credit cards.  There
is a lot more justification with unprotected non-commerce.
And in contrast, there is little justification for
expecting active attacks for purposes of theft.

What this leads to is not whether SSL should have been
deployed or changed in its current form (it is fruitless
to debate that, IMHO, except in order to lay down the
facts) but a discussion of certificates.
There seems some justification in suggesting that SSL be
(continued to be) deployed in any form.  Mostly, IMHO,
in areas outside commerce, and mostly, in the future,
not now.
There seems a lot of justfication for utilising certs as
they enable relationship-protection.  There seems quite a
bit of justification for utilising CA-signed certs because
they permit more advanced relationship protection such as
Amir's logo ideas and my branding ideas, and more so every
day.
What there doesn't appear to be any justification for is
the effective or defacto mandating of CA-signed certs.
And there appears to be a quite serious cost involved in
that mandating - the loss of protection from the resultant
*very* low levels of SSL deployment.
This all hangs on the MITM - hence the question of frequency.
It seems to be very low, an extraordinarily desparate attack
for a criminal, especially in the light of experience.  He
does phishing and hacking with ease, but he doesn't like
leaving tracks in the infrastructure that point back to him.
If the MITM cannot be justified as an ever-present danger,
then there is no justification for the defacto mandating of
CA-signed certs.  Permitting and encouraging self-signed
certs would then make deployment of SSL much easier, and
thus increase use of SSL - in my view, dramatically -
which would lead to much better protection.  (Primarily
by relationship management on the client side, and also
by branding/logo management with the CAs, but that needs
to be enabled in code first at the browsers.)
(It has to be said that encouraging anon-diffie-hellman
SSL would also lead to dramatically improved levels of
SSL 

Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-21 Thread Anne Lynn Wheeler
At 01:54 PM 7/19/2004, Steven M. Bellovin wrote:
It's also worth remembering that an SSL-like solution -- cryptographically
protecting the transmission of credit card number, instead of digitally
signing a funds transfer authorization linked to some account -- was
more or less the only thing possible at the time.  The Internet as a
medium of commerce was too new for the banks to have developed
something SET-like, and there wasn't an overwhelmingly-dominant client
platform at the time for which custom software could be developed.
(Remember that Windows 95 was the first version with an integral TCP/IP
stack.)  *All* that Netscape could deploy was something that lived in
just the browser and Web server.  SET itself failed because the
incentives were never there -- consumers didn't perceive any benefit to
installing funky software, and merchants weren't given much incentive
to encourage it.
SET couldn't replace online transaction ... the encryption was
effectively there for hiding credit card while in-flight ...
which SSL was already doing ... but SET was doing at an
order to two-orders increase in complexity and overhead.
SET didn't provide any additional countermeasure against
the major exploits/vulnerabilities (vis-a-vis SSL) ... even
with all that complexity.
the transaction was still online ... since there are a bunch
of other factors involved in authorization ... like credit limit
... not just whether there is impersonation with lost/stoleln
numbers.
there was still the enormous payload bloat (certificates and
signatures increase the size of typical 8583 transaction by
two-orders of magnitude) which prevent true end-to-end
security operation. As a result the signature was verified
at some internet boundary, then the signature and certificate(s)
were stripped off and traditional 8583 packet forwarded
to the consumer/issuing financial institution. Later at some
ISO standards meeting, one of the association business
people presented numbers on number of 8583 packets
with the signature bit turned on and they positively knew
no digital signature was involved.
It wasn't even a real PKI ...
1) i.e. the x.509 identity certificates from the early 90s had
been depreciated because of the privacy and liability issues
... and the certificates effectively were issuing
relying-party-only certificates with the account number
and public key.
2) there was no revocation and/or other types of process
(which could be considered minimum requirement for
a PKI operation) ... they were simply manufactored
certificates (a term we coined to describe the SET and
SSL infrastructure; contrasting it to PKI). SET
specifically stated that the transaction would be
online and rely on the existing online infrastructure
for determining lost, stolen, revoked, canceled, etc
... as well as all the other stuff an online infrastructure
can do with  timely and aggregated information
(like credit limit)
3) it is trivial to show that for relying-party-only certificates
requiring online infrastructure ... that the certificates
themselves are redundant and superfluous ... aka the
key is registered with the issuing party ... and the transaction
is performed by the issuing party. The transaction can
be digitally signed (w/o the enormous payload bloat of
carrying a certificate) and the issuing party verify the
digital signature with an onfile public key  w/o having
to resort to dealing with a certificate (that the issuing
party would have originally generated from the onfile
information).
From an incentive standpoint the PKI model is effectively
orthogonal to standard business processes.
The key owner pays something to the issuing party (or
at best, the issuing party absorbs the costs). The standard
business process has any sort of contract between the
key owner and the issuing party.
This totally leaves out the relying-party ... which is the
primary beneficiary of the PKI model from being a part
of the contractual business process ... which would imply
little or no legal recourse if something went wrong. GAO
has created a facade to address this issue by making the
TTP certification authorities sort of agents of the GAO ... and
having all relying-parties signed contracts with the GAO.,
The PKI frequently creates a total disconnect between
the parties of the certification contract ... and the
relying parties ... which should have recourse in case
something went wrong aren't even a part of it.
In the specifics of the SET deployment ... the primary
potential beneficiaries theoritically were the merchants
(from the thoery that SET signed transactions would be
considered card-present  card-owner present ... and
lower the merchants cost for doing the transactions).
However the parties paying for the certificates and
most of the infrastructure were the issuers and the
consumers. Not only may a traditional TTP PKI create
legal disconnect for relying parties  but in the SET
case there was major disconnect between who paid for
most of the infrastructure 

Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-18 Thread Eric Rescorla
Ian Grigg [EMAIL PROTECTED] writes:
 Notwithstanding that, I would suggest that the money
 already lost is in excess of the amount paid out to
 Certificate Authorities for secure ecommerce certificates
 (somewhere around $100 million I guess) to date.  As
 predicted, the CA-signed certificate missed the mark,
 secure browsing is not secure, and the continued
 resistance against revision of the browser's useless
 padlock display is the barrier to addressing phishing.

I don't accept this argument at all.

There are at least three potential kinds of attack here:

(1) Completely passive capture attacks.
(2) Semi-active attacks that don't involve screwing with
the network infrastructure (standard phishing attacks)
(3) Active attacks on the network infrastructure.

SSL does a fine job of protecting against (1) and a fairly adequate
job of protecting against (3). Certainly you could do a better job
against (3) if either:

(a) You could directly connect to sites with SSL a la
https://www.expedia.com/
(b) The identities were more user-friendly as we anticipated back in
the days of S-HTTP rather than being domain names, as required by
SSL. 

It does a lousy job of protecting against (3).

Now, my threat model mostly includes (1), does not really include
(3), and I'm careful not to do things that leave me susceptible
to (2), so SSL does in fact protect against the attacks in my
threat model. I know a number of other people with similar threat
models. Accordingly, I think the claim that secure browsing
is not secure rather overstates the case.

-Ekr






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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-18 Thread John Levine
But is it so harmful?  How much money is lost in a typical phishing
attack against a large US bank, or PayPal?

A lot.  According to people at the anti-phishing conference earlier
this year, six-figure losses are common, and seven-figure not unknown.

The kind of phishes we all see, trolling for credit card or ISP
account info with spam, are the lowest level kind.  The serious ones
carefully choose their targets, e.g., ebay sellers with very high
positive ratings, or people who live outside the US and have large US
bank accounts, and are more likely to send hundreds of messages than
millions.

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies,
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
A book is a sneeze. - E.B. White, on the writing of Charlotte's Web

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-18 Thread Ian Grigg
Eric Rescorla wrote:
Ian Grigg [EMAIL PROTECTED] writes:
Notwithstanding that, I would suggest that the money
already lost is in excess of the amount paid out to
Certificate Authorities for secure ecommerce certificates
(somewhere around $100 million I guess) to date.  As
predicted, the CA-signed certificate missed the mark,
secure browsing is not secure, and the continued
resistance against revision of the browser's useless
padlock display is the barrier to addressing phishing.

I don't accept this argument at all.
There are at least three potential kinds of attack here:
(1) Completely passive capture attacks.
(2) Semi-active attacks that don't involve screwing with
the network infrastructure (standard phishing attacks)
By (2) I guess you mean a bypass MITM?
(3) Active attacks on the network infrastructure.
By (3) I guess you mean a protocol level MITM.
Then, there is:
(4) Active attacks against the client.  By this I mean
hacking the client, installing a virus, malware,
spyware or whathaveyou.  (This is now real, folks.)
(5) Active attacks against the server.  Basically,
hacking the server and stealing all the good stuff.
(This has always been real, ever since there have
been servers.)
(6), (7) Insider attacks against client, server.
Just read off the data and misuse it.  (This has
been real since the dawn of time...)
Of course, SSL/SB doesn't protect against any of these,
and many people therefore assume the thinking stops
there.  Sadly, no.  Even though SSL doesn't protect
against these attacks, the frequency  cost of these
attacks directly impacts on the design choices of
secure browsing.
SSL does a fine job of protecting against (1) and a fairly adequate
job of protecting against (3). Certainly you could do a better job
against (3) if either:
(a) You could directly connect to sites with SSL a la
https://www.expedia.com/
(b) The identities were more user-friendly as we anticipated back in
the days of S-HTTP rather than being domain names, as required by
SSL. 

It does a lousy job of protecting against (3).
Sorry, I'm having trouble parsing fairly adequate
versus lousy job for threat (3)...  Both (a) and (b)
seem to deserve some examples?  I can connect directly
to expedia, and https://www.paypal.com/ is friendly
enough?
(Hmmm... I tell a lie, there is no https://www.expedia.com/
as it redirects.)
Now, my threat model mostly includes (1),  does not really include
(3), and I'm careful not to do things that leave me susceptible
to (2), so SSL does in fact protect against the attacks in my
threat model. I know a number of other people with similar threat
models. Accordingly, I think the claim that secure browsing
is not secure rather overstates the case.
(1) OK.  Now, granted, SSL protects against (1), fairly
finely.  It does so in all its guises, although the
CA-signed variant in secure browsing does so at some
additional unneeded expense, as it eliminates certain
secure options, being SSCs and ADH.  OTOH, this is a
really rare attack - actual damage from sniffing HTTP
traffic doesn't seem to be recorded anywhere as a real
attack on people, so forgive me if I downgrade this one
as almost not a threat.
(2) Then we come to (2), what i'd call a bypass MITM.  Or
a phish or a spoof.   (I'm not sure what semi active
and infrastructure have to do with it.)  This one is
certainly a threat.
When the browser is presented with a URL which happens
to purport only to be some secure site, without really
being that site, this is a spoof.  Your defence is to
be careful against this attack.  So, your defence is
nothing to do with SSL or secure browsing or anything really,
literally, (2) is unprotected against by SSL and secure
browsing in all their guises.  You yourself provide the
protection, because SSL / secure browsing does not.  Of
course.
That is my point - secure browsing does not protect
against any real  present threat.
(3)  I don't understand at all.  But you suggest that
it's not your threat and it isn't protected well against.

In summary - we are left with one attack that is well
protected against, but isn't really seen that much,
and could be done with ADH.  Then, another attack that
you deal with yourself, so that's not really relevant
coz you're smart and experienced, and those using
browsers on the average are not, and they are hit by
the attack.  Then there is (3).
(And we haven't even begun on (4) thru (7).  What then,
is a threat model that only includes some threats?)
So in sum, I think my argument remains unchallenged:
secure browsing fails to secure.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-18 Thread Anne Lynn Wheeler
At 05:55 PM 7/17/2004, Eric Rescorla wrote:
Now, my threat model mostly includes (1), does not really include
(3), and I'm careful not to do things that leave me susceptible
to (2), so SSL does in fact protect against the attacks in my
threat model. I know a number of other people with similar threat
models. Accordingly, I think the claim that secure browsing
is not secure rather overstates the case.

there sort of two parts of SSL  I believe the original justification 
was based on perceived integrity issues with the domain name infrastructure 
and various kinds of hijacking attacks. the client got back a certificate, 
verified the integrity of the certificate (from a table of certificate 
authority public keys), verified that it appeared to originate from the 
certificate owner and then compared the certificate domain name string with 
the domain name used in the URL. once that was done, there was key-exchange 
to protect the contents of the transmission.

the catch22 was that the domain name infrastructure is also the 
authoritative agency as to the owner of the domain name. the SSL domain 
name certification authorities have this horrendously, error prone and 
expensive problem of getting sufficient identification information from the 
certificate applicant and attempting to match it with the identification 
information carried by the domain name infrastructure as to the owner of 
the domain name.

so the first issue is that the integrity of the domain name infrastructure 
could be attacked with a domain name hijack ... then the attacker applies 
for a certificate  and the identification provided the certification 
authority and the identification on file with the domain name 
infrastructure compare ... and the attacker gets a valid certificate.

so the certification authorities came up with a proposal to have domain 
name registers  also supply a public key at the time of registration. 
then future communication with the domain name owner is digital signed ... 
which the domain name infrastructure can verify with the public key on 
file. this is a countermeasure against domain name hijacking (improving the 
integrity of the domain name infrastructure and rising the trust that 
certification authorities can place in the authoritative agency). the other 
issue is that the certification authorities can use the public key on file 
with the domain name infrastructure to turn an expensive, and error-prone 
identification process into a much simpler and KISS authentication process 
 aka domain name certificate applicants digitally sign their requests 
... which are then verified with the public key on file at the domain name 
infrastructure.

the two issues then are that with increased domain name infrastructure 
trust ... 1) it should reduce the demand for domain name SSL certificates 
(motivated by integrity concerns about the domain name infrastructure) and 
2) it could eliminate the need for domain name SSL certificates  since 
all clients could possibly also use the public keys on file with the domain 
name infrastructure (in lieu of needing to get public keys from certificates).

So now to the key-exchange issue protecting credit-card numbers from 
evesdropping and harvesting. The issue is that the crooks tend to go after 
the best fraud ROI (return on investment). The claim is that it is so much 
more profitable to harvest the merchant transaction file  that until 
that barn door is closed  the crooks have little incentive to go after 
credit card numbers by evesdropping packets in flight. There have been some 
assertions that there has been no known cases of picking up account numbers 
from packet evesdropping  even where SSL or any other encryption is 
being used to protect data in-flight. Part of the issue is that 
evesdropping packets takes a lot more work ... and provides much less 
return than going after the merchant transaction file. Other scenarios have 
also been end-point attacks ... where password files are harvested and/or 
viruses are installed at end-points to harvest information  as opposed 
to doing anything with data in-flight.

So, it could be claimed that there is some question about what is cause and 
what is effect i.e. are the end-point attacks because everything is 
encrypted  or are the end-point attacks occurring because they are so 
much more profitable and easier. Given that there are significant amounts 
of non-encrypted traffic ... then the claim could be made that the crooks 
are getting so much more from end-point attacks ... and until that is 
addressed ... that attacks on data in flight is somewhat academic (since 
there is so little evidence about fraud happening from data in flight 
attacks). The other argument has traditional been that 90 percent of fraud 
has been insiders, typically also associated with various kinds of 
end-point attacks (rather than any kind of outsider attack on data in 
flight). There was some recent 

Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-18 Thread John Denker
Enzo Michelangeli wrote:
Can someone explain me how the phishermen escape identification and
prosecution? Gaining online access to someone's account allows, at
most, to execute wire transfers to other bank accounts: but in these
days anonymous accounts are not exactly easy to get in any country,
and anyway any bank large enough to be part of the SWIFT network
would cooperate in the resolution of obviously criminal cases.
Good question.
Actually there are two questions we should consider:
 a) What are the procedures phishermen are using today,
procedures that they manifestly *can* get away with?
 b) Why why why are they allowed to get away with such
procedures?
Here is something of an answer to question (a):
http://www.esmartcorp.com/Hacker%20Articles/ar_Watch%20a%20hacker%20work%20the%20system.htm
The details are a bit sketchy, and maybe not entirely to
be trusted since they come from self-described crooks,
but they are plausible.
Still question (b) remains.  The described procedures seem
to be the e-commerce analog of parking your car in a bad
neighborhood with the windows rolled down and the keys in
the ignition.  That is, I expect that most people on this
list could easily think of several things the card-issuers
could do that would shut down these attack-procedures,
significantly raising the phishermen's work-factor and risk
of arrest -- without significantly burdening legitimate
merchands or cardholders.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-18 Thread Ian Grigg
Enzo Michelangeli wrote:
Can someone explain me how the phishermen escape identification and
prosecution? Gaining online access to someone's account allows, at most,
to execute wire transfers to other bank accounts: but in these days
anonymous accounts are not exactly easy to get in any country, and anyway
any bank large enough to be part of the SWIFT network would cooperate in
the resolution of obviously criminal cases.
In practice something like this:  Most of the
money is wired through to some stolen account,
and then moved out of the system to another system.
This might be a foreign account, or it might be a non-
bank such as a broker/dealer (E*Trade is being hit at
the moment, it seems) or it might be a digital gold
currency.  From there, it is moved once or twice more,
than back to the country where the phisher is.  This
might be the US or Russia, or anywhere else, but those
two countries seem to be quite big on this (maybe we
should blame Reagan :-) )
A couple of things:  it is very hard, but not impossible
to reverse a SWIFT style international wire.  I've seen
it done once, so I know it is not impossible.  If the
cash has gone, then reversing it doesn't make sense.
Also, phishing
isn't exactly a recognised and obvious criminal case.
Any particular instance might be, but getting to that
determination might take months.  Further, opening
accounts for anonymous purposes is still rather easy
in many countries, the chief perpertrator of this being
the USA.  Finally, every attempt to make money less like
money (by closing off easy accounts, for example) results
in what some call unintended consequences - the money
goes elsewhere.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-17 Thread Anne Lynn Wheeler
At 10:46 AM 7/10/2004, Florian Weimer wrote:
But is it so harmful?  How much money is lost in a typical phishing
attack against a large US bank, or PayPal?  (I mean direct losses due
to partially rolled back transactions, not indirect losses because of
bad press or customer feeling insecure.)
misc. recent selections
Online Phishing Scams Exploding
http://itmanagement.earthweb.com/secu/article.php/3382341
Business faces growing loss from identity theft
http://www.vnunet.com/news/1156655
Firms hit hard by identity theft
http://www.boston.com/business/technology/articles/2004/07/14/firms_hit_hard_by_identity_theft/
ID theft costing UK billions in taxes
http://news.zdnet.co.uk/0,39020330,39160532,00.htm
ATM skimmers go hi-tech down under
http://www.finextra.com/fullstory.asp?id=12184
Phishing will cost financial firms $400m in 2004
http://www.finextra.com/fullstory.asp?id=12173
Worried firms consider email boycott
http://www.vnunet.com/news/1156684
=
social engineering has frequently been talking somebody into giving up some 
information that then can be used for impersonation in later fraudulent 
transactions. A something you have token of some sort is a lot harder to 
give-up than shared-secrets for use in something you know authentication. 
A private key that never leaves the hardware token can't be given up 
because even the owner doesn't know it. also, conjecture is that it is a 
lot harder to convince general public to mail off some physical object 
compared to getting them to divulge some information.

hardware tokens don't eliminate social engineering attacks where the victim 
is talked into performing some transaction on behalf of the attacker ... 
but they would tend to address the whole vulnerability landscape related to 
something you know shared-secret authentication paradigms.

one of the cost issues with technology for server reputation is that it 
typically applies to servers that the consumer is visiting for the first 
time (or visits extremely rarely). the consumer pretty much ignores 
repetitive information for sites that they visit frequently. it has been 
that something like ninety percent (or better) of internet transactions are 
done by the frequently visited sites. so the cost issue is that the 
reputation technologies basically tend to apply to the millions of 
low-volume and/or low-revenue sites (in aggregate accounting for 10 percent 
or less of all transactions) ... which aren't looking to spend a lot of 
money on such technologies.

it is somewhat like the better business bureau use  people will tend to 
contact the better business bureau before they deal with some vendor for 
the first time  but they aren't likely to contact the better business 
bureau each time they deal with a vendor that they have extensive repeat 
business with. it at least some scenarios 

an alternative to the business logo  is a  better business bureau or 
gov. licensing logo on a website  that provides click-thru to the 
official site  where the consumer can review complaints and/or history 
about the business in question. i believe that this is somewhat the ebay 
model ... where past transaction history reputation of individuals can be 
checked.

--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/ 

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-17 Thread Ian Grigg
At 10:46 AM 7/10/2004, Florian Weimer wrote:
But is it so harmful?  How much money is lost in a typical phishing
attack against a large US bank, or PayPal?  (I mean direct losses due
to partially rolled back transactions, not indirect losses because of
bad press or customer feeling insecure.)
I estimated phishing losses about a month ago at about
a GigaBuck.
http://www.financialcryptography.com/mt/archives/000159.html
You'll also see two other numbers in that blog entry,
being $5 billion and $400 million (the latter taken
from Lynn's posted articles).
Of course these figures are very delicate, so we need
to wait a bit to get the real damage with any degree
of reliability.  Scientific skepticism should abound.
Notwithstanding that, I would suggest that the money
already lost is in excess of the amount paid out to
Certificate Authorities for secure ecommerce certificates
(somewhere around $100 million I guess) to date.  As
predicted, the CA-signed certificate missed the mark,
secure browsing is not secure, and the continued
resistance against revision of the browser's useless
padlock display is the barrier to addressing phishing.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-15 Thread Rich Salz
 SET failed due to the complexity of distributing the software and setting
 up the credentials.  I think another reason was the go-fast atmosphere of
 the late 90s, where no one wanted to slow down the growth of ecommerce.
 The path of least resistance was simply to bring across the old way of
 authorizing transactions by card number.

I think your other reason was in fact the primary reason.  And, of course,
the primary enablers of the go-fast approach were, in fact, the very same
credit card companies.  They made a conscious business decision to treat
online transactions the same as conventional transactions -- I forget the
details, but it was pretty risk-free for a merchant to do online credit
cards, getting low surchage rates.  That, coupled with the US law that
limited consumer liability to $50, made CCard-over-SSL a no-brainer over
SET.

From a consumer viewpoint, CC/SSL is more secure then SET ever was.  Since
it wasn't a CCard transacdtion, my liability under SET was unlimited (at
least until Congress caught up to the technology).  Looking at the risk
management aspect, SET was a big loser for the customer.

/r$

--
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-11 Thread Ian Grigg
Florian Weimer wrote:
There are simply too many of them, and not all of them implement
checks for conflicts.  I'm pretty sure I could legally register
Metzdowd in Germany for say, restaurant service.
This indeed is the crux of the weakness of the
SSL/secure browsing/CA system.  The concept
called for all CAs are equal which is an
assumption that is easily shown to be nonsense.
Until that assumption is reversed, the secure
browsing application is ... insecure.  (I of
course include no CA and self-signed certs
within the set of all CAs.)
The essence of any fixes in the browsers should
be to address the (rather fruitful) diversity
amongst CAs, and help the user to make choices
amongst the brands of same.
Some CAs are more equal than others... and the
sooner a browser recognises this, the better.
These bodies could issue logo certificates.

These certificates would only have value if there is extensive
verification.  We probably lack the technology to do that cheaply
right now, and the necessary level of international cooperation.
I'm not sure I understand how logo certs would
work, as there is still the possibility of same
being issued by CA-Nigeria and having remarkable
similarity to those issued by USPTO.
Until the CA is surfaced and thrust at the face
of the user, each browser's 100 or so root CAs
will be a fundamental weakness.  Including of
course the absence of CA, which is something
that is nicely hidden from the user.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-11 Thread Amir Herzberg
Ian Grigg wrote:
This indeed is the crux of the weakness of the
SSL/secure browsing/CA system.  The concept
called for all CAs are equal which is an
assumption that is easily shown to be nonsense.
Exactly. Browsers simply require sites to have a certificate from any 
CA. Browswers can't even specify a list of their prefered/acceptable 
CA... This made it easier for SSL to roll-out, but, like you say, made 
certificates into commodities and almost meaningless.
skip
The essence of any fixes in the browsers should
be to address the (rather fruitful) diversity
amongst CAs, and help the user to make choices
amongst the brands of same.
Agreed!
Some CAs are more equal than others... and the
sooner a browser recognises this, the better.
Agreed! Except, I think that the user may also be involved in 
recognizing the more trustworthy CA, e.g. by including also a logo of 
the CA in the TCA - so I can see, `this site is IBM (since I see their 
logo) and this was validated by Verisign and/or the USPTO (since I see 
their `logo certified by` logo(s)).

These bodies could issue logo certificates.
Exactly!
These certificates would only have value if there is extensive
verification.  We probably lack the technology to do that cheaply
right now, and the necessary level of international cooperation.
I'm not sure I agree here. I think that many logos (e.g. of 
international companies) are already well protected by the existing 
network of trade mark offices. As to smaller companies, they would be 
protected by the logo but also by including icons/seals of credentials 
in the Trusted Credentials Area. E.g., getting back to your example, a 
site such as Perry's, which contain professional crypto information, 
should be able to get a credential from organizations such as IACR or 
ACM or Financial Cryptography or... and I guess these places would not 
give a credential (certainly not to the same logo) for a resturant.

So, the site logo becomes more meaningful when accompanied by the Logo 
Certifying Authority logo, and/or by appropriate credentials.
I'm not sure I understand how logo certs would
work, as there is still the possibility of same
being issued by CA-Nigeria and having remarkable
similarity to those issued by USPTO.
Let's not pick on Nigeria, but I get your point; but why should you set 
your browser to trust logo certificates from an LCA you don't trust?? 
The site can obtain multiple logo certificates if it wants its logo to 
be internentionally trusted.
Until the CA is surfaced and thrust at the face
of the user, each browser's 100 or so root CAs
will be a fundamental weakness.  Including of
course the absence of CA, which is something
that is nicely hidden from the user.
Agreed. We already planned to have the LCA's logo in the TCA but I'll 
modify the paper (and code) to make this more clear and visible. Thanks!

BTW, notice that by default, and considering there is no CA certifying 
logos yet afaik, you simply have to validate the (regular) certificate 
on the first time you get a public key from the server...
--
Best regards,

Amir Herzberg
Associate Professor, Computer Science Dept., Bar Ilan University
http://amirherzberg.com (information and lectures in cryptography  
security)
begin:vcard
fn:Amir  Herzberg
n:Herzberg;Amir 
org:Bar Ilan University;Computer Science
adr:;;;Ramat Gan ;;52900;Israel
email;internet:[EMAIL PROTECTED]
title:Associate Professor
tel;work:+972-3-531-8863
tel;fax:+972-3-531-8863
x-mozilla-html:FALSE
url:http://AmirHerzberg.com
version:2.1
end:vcard



Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-10 Thread Florian Weimer
* Amir Herzberg:

 Florian Weimer wrote:

 * Amir Herzberg:

# Protecting (even) Naïve Web Users, or: Preventing Spoofing and
Establishing Credentials of Web Sites, at
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF
 The trusted credentials area is an interesting concept.
 Thanks.
   However,
 experience suggests that given the current business models, we cannot
 build the required logotype registry.  All registries which are used
 on the Internet (for IP address assignments, BGP prefixes, DNS names,
 and even X.509 certificates) are known to fail under stress.

 I'm not sure what you mean by `logotype registry`.

A body which registers visual elements etc. and assigns them to an
owner.

 Such a registry already exist (off-web), i.e. national trademark
 offices, e.g. www.uspto.gov.

There are simply too many of them, and not all of them implement
checks for conflicts.  I'm pretty sure I could legally register
Metzdowd in Germany for say, restaurant service.

 These bodies could issue logo certificates.

These certificates would only have value if there is extensive
verification.  We probably lack the technology to do that cheaply
right now, and the necessary level of international cooperation.

 Or, private companies, e.g. verisign, can issue logo certificates,
 based on the official trademark registers; that shouldn't be hard.

But it is, it all boils down to who does the verification, and who
pays for it.  Identifying someone is not that hard, of course, but how
do you know if he or she is authorized to use a resource (be it a
trademark or an IP subnet)?

 As to a registry to hold these certificates - the site (e.g. bank)
 would probably keep it... and many other places (this is signed
 i.e. not risky to keep).

You still have to handle revocation.  Mistakes will happen. 8-/

 Finally, of course, until such certificates are available, we simply
 use the manual binding of logos/icons/names to public keys, on the
 first time you enter a secure site using a browser with our
 enchancement. It works great... very convenient, and very clear (see
 screen shots in paper).

Ah, I missed that part.  This could be rather helpful if users are
able to understand the concept.  Have you run any usability tests?

BTW, you can emulate it by removing all root CAs from your browser,
and just relying on previously stored certificates.  Works rather
well, although some people who have different threat models sneer at
it.

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-10 Thread Florian Weimer
* Hal Finney:

 Only now are we belatedly beginning to pay the price for that decision.
 If anything, it's surprising that it has taken this long.  If phishing
 scams had sprung up five years ago it's possible that SET would have
 had a fighting chance to survive.

Wouldn't typical phishing attacks just read like:

| We have upgraded our e-commerce server software.  In order to use
| your PayPal account after August 1, 2004, you have to upgrade your
| Elecontric Wallet.  This upgrade is free.  Download it from:
|
|   http://www.example.com/downloads/set_upgrade.exe

 I predict that we will eventually move to a SET-like system; not
 necessarily that exact protocol, but something based on cryptographic
 authorizations for online purchases rather than the card number based
 systems in use today.

I talked to a financial services provider recently, and they were
scared when I proposed that.  It brings back horrible memories.  To
them, the avent of Java-less SSL banking was a real breakthrough.  It
seems that end-user support issues have plummeted.

Even some form of pre-registration of banking sites seems infeasible.
In Germany, we have a standard called HBCI which supports smart cards
and signed transactions (providing, in theory, end-to-end
verifiability), but support overhead seems to be much larger.

There still remains the issue that you can provide a good visual
approximation to any peace of software just by using JavaScript and
HTML.  I fear that too many users would fall for that. 8-(

 In considering such solutions, it is important to distinguish threat
 models.  Phishing is so harmful because it succeeds without even breaking
 in to users' computers.

But is it so harmful?  How much money is lost in a typical phishing
attack against a large US bank, or PayPal?  (I mean direct losses due
to partially rolled back transactions, not indirect losses because of
bad press or customer feeling insecure.)

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-09 Thread Anne Lynn Wheeler
At 10:40 AM 7/7/2004, Hal Finney wrote:
SET failed due to the complexity of distributing the software and setting
up the credentials.  I think another reason was the go-fast atmosphere of
the late 90s, where no one wanted to slow down the growth of ecommerce.
The path of least resistance was simply to bring across the old way of
authorizing transactions by card number.

both SET  SSL encrypted data in transit. an issue is that SET is 
significantly more complex and provided no additional countermeasure 
(vis-a-vis SSL) against major remaining exploits  like harvesting the 
merchant transaction file while at rest.

there was some issue that SSL was the incumbent ... so SET had to 
demonstrate significant better ROI to displace it ... rather than 
significantly higher I with little or no additional R.

some SSL:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
the security proportional to risk reference (using merchant transaction 
file as example)
http://www.garlic.com/~lynn/2001h.html#61

couple minor past refs related to SET business operations
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: 
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: 
crypto flaw in secure mail standards

another SET issue was that it took a typical ISO 8583 transaction of 60-80 
bytes and added a RSA 128 digital signature and issuing certificate of 
4k-12k bytes  effectively increasing the payload size by a factor of 
two orders of magnitude. it stripped all the SET overhead off at the 
internet boundary and transmitted a traditional 8583 message (in part 
because it was difficult to justify a 100-fold increase in payload size for 
no obvious benefit) with a flag indicating whether the signature had 
verified. There was some presentation at an ISO meeting by one of the 
association business people about the number of 8583 messages with the 
signature-verified flag turned on and they absolutely knew that there was 
no SET technology involved (some justification was association was 
proposing rules that transactions with the flag on would have lower 
merchant fees). missing is that typical authorization includes a lot of 
dynamic and aggregation factors (like credit limit) that are totally 
missing in a simple certificate-based (offline) authentication model. In 
fact, most infrastructures that involve transactions of any value have 
migrated and/or are migrating to online infrastructures that involve timely 
and/or aggregated information  something that is missing from a purely 
offline, certificate-based, static, stale data infrastructure.

misc. implications
1) given an online transaction environment, it is then trivial to show that 
certificates are redundant and superfluous ... because it is possible to 
access the timely updated copy of the information rather than having to 
rely on the stale, static copy of the certificate information (designed to 
satisfy an offline environment requirement)

2) certificate market then becomes relegated to both offline and no/low 
value (as infrastructures of value migrate to online paradigms) ... there 
is little/no justification for paying money for certificates if only no/low 
value infrastructures are involved.

3) w/o significant funding for certificate-based infrastructure, there is 
little money to underwrite high-integrity certificate-based operations

4) with no high-integrity certificate-based operations, it is difficult to 
justify using certificates for high-value operations

5) go to #2
as has past frequently noted, the requirement given the x9a10 retail 
payments working group for the x9.59 standard was to preserve the integrity 
of the financial infrastructure for all retail payment environments. one of 
the considerations was being able to accommodate end-to-end integrity ... 
aka the financial responsible entity for authorizing the transaction also 
performs the authentication. another issue x9a10 had to address was to 
address other kinds of risks  like the merchant transaction file where 
the information traditionally has to occur in the clear to support normal 
business operations (offer something more than the encryption of data 
in-flight).
http://www.garlic.com/~lynn/index.html#x959

lots of posts about certificate infrastructures
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
misc. stuff on x9.59, identity, authentication, and privacy
http://www.garlic.com/~lynn/subpubkey.html#x959
--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/ 

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-09 Thread Anne Lynn Wheeler
At 10:40 AM 7/7/2004, Hal Finney wrote:
SET failed due to the complexity of distributing the software and setting
up the credentials.  I think another reason was the go-fast atmosphere of
the late 90s, where no one wanted to slow down the growth of ecommerce.
The path of least resistance was simply to bring across the old way of
authorizing transactions by card number.

the other issue was rsa public key op overhead (besides extreme payload
bloat, extreme additional complexity, and no significant countermeasures for
prime exploits compared to e-commerce incumbent SSL).
when the initial set specification was published, i did a business profile and
a performance profile (including public key operations profile). somebody
i knew was playing with bsafe library and tweaked it to run four times
faster. I got him to run the set public key op profile on a number of 
processors.

i mentioned the numbers at some set get together and the response from
the set people was that it was 100 times too slow (if they had ever run
any bsafe they should have realized that it was four times too fast).
anyway ... sometime later when they actual set implementations running ...
the earlier profile numbers were within a couple percent of measured on
actual implementations.
i also observed that given nominal extended peak avgs. of 1000/transactions
per sec  that if SET ever actually became mainstream operational 
(rather than
just toy pilots) ... processing would need something like 100,000 to 250,000
extra processors to handle the RSA op processing load. the counter argument
was that SET would take so long to became mainstream ... that by
then CPUs might be ten to 100 times faster and it might only
require 10,000 to 25,000 (or 1,000 to 2,500) extra processors.

--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/  

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-08 Thread Amir Herzberg
Florian Weimer wrote:
* Amir Herzberg:

# Protecting (even) Naïve Web Users, or: Preventing Spoofing and
Establishing Credentials of Web Sites, at
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF

The trusted credentials area is an interesting concept. 
Thanks.
 However,
experience suggests that given the current business models, we cannot
build the required logotype registry.  All registries which are used
on the Internet (for IP address assignments, BGP prefixes, DNS names,
and even X.509 certificates) are known to fail under stress.
I'm not sure what you mean by `logotype registry`. Such a registry 
already exist (off-web), i.e. national trademark offices, e.g. 
www.uspto.gov. These bodies could issue logo certificates. Or, private 
companies, e.g. verisign, can issue logo certificates, based on the 
official trademark registers; that shouldn't be hard.

As to a registry to hold these certificates - the site (e.g. bank) would 
probably keep it... and many other places (this is signed i.e. not risky 
to keep).

Finally, of course, until such certificates are available, we simply use 
the manual binding of logos/icons/names to public keys, on the first 
time you enter a secure site using a browser with our enchancement. It 
works great... very convenient, and very clear (see screen shots in paper).
--
Best regards,

Amir Herzberg
Associate Professor, Computer Science Dept., Bar Ilan University
http://amirherzberg.com (information and lectures in cryptography  
security)
begin:vcard
fn:Amir  Herzberg
n:Herzberg;Amir 
org:Bar Ilan University;Computer Science
adr:;;;Ramat Gan ;;52900;Israel
email;internet:[EMAIL PROTECTED]
title:Associate Professor
tel;work:+972-3-531-8863
tel;fax:+972-3-531-8863
x-mozilla-html:FALSE
url:http://AmirHerzberg.com
version:2.1
end:vcard



Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-08 Thread Hal Finney
There was an early attempt to use cryptography to authenticate online
credit card transactions, the SET protocol pushed by Visa and Mastercard
in the late 1990s.  SET would require PC users to download a digital
wallet application which would hold cryptographic credentials that
would be used to authorize a transaction.  The wallet software would
then issue a digital signature when the user approved a purchase.

SET failed due to the complexity of distributing the software and setting
up the credentials.  I think another reason was the go-fast atmosphere of
the late 90s, where no one wanted to slow down the growth of ecommerce.
The path of least resistance was simply to bring across the old way of
authorizing transactions by card number.

Only now are we belatedly beginning to pay the price for that decision.
If anything, it's surprising that it has taken this long.  If phishing
scams had sprung up five years ago it's possible that SET would have
had a fighting chance to survive.

I predict that we will eventually move to a SET-like system; not
necessarily that exact protocol, but something based on cryptographic
authorizations for online purchases rather than the card number based
systems in use today.

In considering such solutions, it is important to distinguish threat
models.  Phishing is so harmful because it succeeds without even breaking
in to users' computers.  A SET-like system can protect against such scams.
Defending against breakin attacks is a harder problem, but that doesn't
mean that solving the easier problem is useless.

Contrary perhaps to the conventional wisdom, I am optimistic that
we will see increases in computer security over the next several years
and that break-ins, although not eliminated, will be greatly reduced.
This model makes it even more important to move towards cryptographic
assurance for payment systems.

Hal Finney

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


Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-07 Thread Florian Weimer
* Amir Herzberg:

 # Protecting (even) Naïve Web Users, or: Preventing Spoofing and
 Establishing Credentials of Web Sites, at
 http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF

The trusted credentials area is an interesting concept.  However,
experience suggests that given the current business models, we cannot
build the required logotype registry.  All registries which are used
on the Internet (for IP address assignments, BGP prefixes, DNS names,
and even X.509 certificates) are known to fail under stress.

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


Using crypto against Phishing, Spoofing and Spamming...

2004-07-04 Thread Amir Herzberg
Following some of our discussions on this list, I tried to think more 
seriously on how crypto could be used for the basic current security 
threats of spoofing, phishing and spamming. Preliminary write-ups of the 
results are available in the following (or from my homepage):

# Protecting (even) Naïve Web Users, or: Preventing Spoofing and 
Establishing Credentials of Web Sites, at 
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/trusted%20credentials%20area.PDF

# Controlling Spam by Secure Internet Content Selection, at 
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spam.pdf

I believe many of you will find some interest in (criticizing?) the new 
ideas and proposals, and I'll be very grateful for any feedback; the 
works already benefited a lot from some discussions on this list, 
including some of you who asked me essentially to `write up your ideas`.

I am also very interested in working with potential implementors; I am 
already working on implementations with students, but, additional and 
potentially more experienced developers may help us turn some of these 
ideas into reality.

BTW, I'm already using the anti-spamming mechanism (trusted logo and 
credentials area) we developed for Mozilla, and it works great; I hope 
we'll feel soon confident enough with the code so we'll be able to put 
it in the public domain. Experienced Mozilla developers who will be 
willing to help test and evaluate the code are invited to contact me.

--
Best regards,
Amir Herzberg
Associate Professor, Computer Science Dept., Bar Ilan University
http://AmirHerzberg.com (information and lectures in cryptography  
security)

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