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.