From: Ian Grigg <iang@systemics.com>
Subject: Making VeriSign like CocaCola - How CA Branding works against Phishing, substitute CA attack, etc etc
Date: Mon, 12 Jul 2004
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040707)
To: Amir Herzberg <herzbea@macs.biu.ac.il>
CC: Fritz Schneider <fritz@google.com>, mozilla-security@mozilla.org

[Guys, I've added the mozilla-security group to this thread.
We are discussing this proposal:
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm ]

Amir Herzberg wrote:
> Ian, I mostly agree; in particular, I agree that the fact that 
> (all/most/many/some...) browsers will display the CA logo together with 
> the site's logo or name, will be an incentive to CAs (or others) to 
> certify logos, i.e. become LCAs.

OK.  I have no objection to (for example) the TCA/branding
box also displaying the logo of the site.  I suppose what
one would propose is that a client certificate package
could include the cert, and logos according to some agreed
formula.

(See screen shots of Mozilla in above URL.)

Then, the browser could examine the cert as presented,
and request the standard logos from standard places (and
examine the sigs on those).

So it might be a thing of defining the potential package
of initial cert signing as including some logo formats.
(length and width in pixels for example).

Now, one thing that should be done from a marketing pov
is to clearly show that a LCA (logo cert authirity) has
control over the nature of the package delivered, and
could happily sell a range of packages for different
prices [1].  This allows the LCA to differentiate.  A
it like airlines, selling the same seat for 3 times as
much because it is at the front of the plane.

(I've written elsewhere on why the market for CA-signed
certs is as dead as a dodo [2].  While last month's
figures show some overall growth in the market, Verisign's
grip continues to slip due to lack of branding and
commoditisation [3].  I wonder when they'll get it?)

> But notice this by itself does not make
> an incentive to actually confirm the logos... the incentive to this 
> should be the usual incentive of review and certification bodies, i.e., 
> that if their certification is given without proper validation, it will 
> become meaningless (and not accepted into the TCA of all/most/many/... 
> browsers).

I'm only going to address the CA's logos here:  I
think these will be easily confirmable.  Here is
what I propose and why I believe there is no problem
whatsoever in confirming the CA logo set:

Each CA's root is expanded to include the logo set.
E.g., the default root list of Mozilla includes for
each CA a root cert, a small logo and a big logo [4].
The root cert and the logos are cryptographically
tied together for convenience of checking although
this is not a big deal [5].

Then, the package for each CA is published on the
Mozilla web pages.  That is, we can go to a site
page such as mozilla.org/root_certs/CACert/ and
on that page will be presented the logos in a
standard fashion.  There should be a mailing list
to which new proposed packages are submitted, and
I'd even go so far as to send out the logos as
attachments (!) so that no subscriber has any
excuse.

What does all this mean?  Within the community of
100 or so CAs that are honoured in Mozilla's default
root list, it would be relatively easy for them all
to watch the new proposed root packages and spot
any problems.  E.g., if some Ugandan CA started
proposing VeliSlime logos and certs, that just
happened to bear an uncanny resemblance to VeriSign,
then the latter CA would simply raise the reg flag,
and all would stop.  MF would convene a dispute
resolution process, wait the results and then kick
out the VeliSlime pretender [6].

When the default root list goes out, the browser
includes on disk the set of CA certs *and* the CA
logos.  The browser displays the CA logos on the
branding box on the chrome, and does all the other
good stuff that browsers already do (don't forget
to count the cert visits and present the number to
the user as well).



What does this get the user?  Hey presto, MITM
attacks that now easily breach secure browsing are
addressed [7].  The space of MITM attacks can be
divided four ways, thusly:

1.  If the scammer gets a real VeriSign cert, then
VeriSign now has an incentive to monitor the usage
of the cert.  That is, if the scammer succeeds in
ripping off a bunch of book-buying mamas, then VeriSign
is on the hook for BOTH legs of the transaction (so to
speak).  So VeriSign polices its space *within* its set
of customers.

2.  If the scammer gets an Anazom cert from the
ChineseMinistryOfIntellectualProperty, a known and
accepted CA, and then deploys that in an attack,
the user should notice the change in brand of CA.  Of
course, Amazon, having purchased the premium Verisign
package, will have been displaying the VeriSign logos
in that branding box for years.

The users can see that change.  They can see that
change like they see a change in adverts on the TV,
because it is branding and it is designed to give
the user a sense of comfort when there, a sense of
worry when not [8].

So, the users now police the space *between* the CAs.

3.  If the scammer uses a self-signed cert (SSC),
then the branding box shows "Self-Signed Cert" in
very boring, non-logo grey.  The user can notice
this as above.  Same, same - if the user expects
an SSC, then all is well and good.  If not, then
raise red flag [9].

So, the user (and the browser together) police the
SSC space by looking at the bland display and the
count of uses of that cert.

4.  If the scammer doesn't use a cert at all, then
the branding box shows a black hole with the number
zero.  The user can notice this [10].

This way, the user and browser now police the
unprotected space.



Compare and contrast to say that old Key thing.
What went wrong with the Key or the little green
Tick or whatever it was, was that the user was
given a useless message:  If the key is there the
session is encrypted.  If it is halfway, then
it's not encrypted enough.  Oh, and maybe it is
authenticated, but we aren't really saying much
about that because all it really does is get you
to this URL...

Caught between two forces (a, the crypto wars on
key strength and exportability and b, the total
absence of any threat to browsing) the Key was
downgraded and forgotten, by the users, by the
GUI people, and seemingly by CAs as well.

Yet, now, we have our first real threat, in the
form of phishing [11], and we can now see that what
is needed is not crypto strength, but a CA brand:
you can't tell the user that 40 bits is ok but 128
bits is better.

But you can tell the user that Citibank uses
GeoTrust certs, and if that pretty picture of
the red arrow/blue corner changes, watch out [12].


iang


[1]  LCA == Logo Certificate Authority, being a CA
that certifies logos as well as domain certs.

[2]  http://iang.org/ssl/dr_self_signed.html

[3]  http://www.securityspace.com/s_survey/sdata/200406/certca.html

[4]  By logo, I mean here more than just a symbol,
there could be messages, there could be whatever
as a group, the CAs could negotiate with the browser
manufacturers given space and GUI considerations to
get standardised into a dialog.

[5]  E.g., the root cert includes a hash of the
logos, or there is a separate signed message over
the logos.  I wouldn't propose necessarily that
the logos be signed in their own format.  Also,
bear in mind that even though they might be tied
together, a likely attack on the PC's disk would
result in the entire set being replaced, so it
makes little odds.

[6]  Don't be scared by this - it would already
be formed in the presence of a CA's mailing list,
and the *other* CA's would chime in and say, kick
that fraudster outa here.  An attack on one CA is
an attack on all.  Dispute resolution is very
easy when the info is right there and the incentives
are aligned.

[7]  To my knowledge there are three MITMs that
breach secure browsing:  Phishing, substitute CAs,
and click-through-syndrome.  The branding of CAs
addresses each of these in part, and should be
accompanied by the other techniques mentioned
elsewhere (cert counting, SSC promotion, and
default use of SSCs by servers).

[8]  Just as an aside, this branding trick is
used to secure payment readers for direct debit
and smart card money the world over.  Why this
works is beyond today's scope.

[9]  Notice how SSCs are *good* because a site
using one has a positive incentive to upgrade to
a CA-signed cert.

[10]  Notice how the absence of any cert now becomes
an issue:  if there is any reason for any security,
the user can say, come on guys, at least put in a
SSC, they're free....  (Well, they're only free in
money, the browsers and servers still do stupid
things like claim they are dangerous.  The good
news is that browser and server security can only
improve with the usage of SSCs.)

[11]  Phishing is widely reported everywhere,
except in Internet security circles.  Try this
selection:
http://www.financialcryptography.com/cgi-bin/mt/mt-search.cgi?IncludeBlogs=2&search=Phishing

[12]  Note that the user and the browser work
*together* on this.  The user watches the CA brand,
and the browser counts the cert visits.  Between
the two, this pretty much knocks a hole in the
current phishing epidemic.