Trouble in PKI land

The CA and PKI business is busy this week. CAcert, a community Certification Authority, has a
special general meeting to resolve the trauma of the collapse of their audit process. Depending on
who you ask, my resignation as auditor was either the symptom or the cause.

In my opinion, the process wasn't working, so now I'm switching to the other side of the tracks.
I'll work to get the audit done from the inside. Whether it will be faster or easier this way is
difficult to say, we only get to run the experiment once.

Meanwhile, Mike Zusman and Alex Sotirov are claiming to have breached the EV green bar
thing used by some higher end websites. No details available yet, it's the normal tease before a
BlabHat style presentation by academics. Rumour has it that they've exploited weaknesses in the
browsers. Some details emerging:

With control of the DNS for the access point, the attackers can establish their machines as men-
in-the-middle, monitoring what victims logged into the access point are up to. They can let
victims connect to EV SSL sites - turning the address bars green. Subsequently, they can redirect
the connection to a DV SSL sessions under a certificates they have gotten illicitly, but the
browser will still show the green bar.

Ah that old chestnut: if you slice your site down the middle and do security on the left and no or
lesser security on the right, guess where the attacker comes in? Not the left or the right, but up
the middle, between the two. He exploits the gap. Which is why elsewhere, we say "there is only
one mode and it is secure."

Aside from that, this is an interesting data point. It might be considered that this is proof that the
process is working (following the GP theory), or it might be proof that the process is broken
(following the sleeping-dogs-lie model of security).

Although EV represents a good documentation of what the USA/Canada region (not Europe)
would subscribe as "best practices," it fails in some disappointing ways. And in some ways it has
made matters worse. Here's one: because the closed proprietary group CA/B Forum didn't really
agree to fix the real problems, those real problems are still there. As Extended Validation has
held itself up as a sort of gold standard, this means that attackers now have something fun to
focus on. We all knew that SSL was sort of facade-ware in the real security game, and didn't
bother to mention it. But now that the bigger CAs have bought into the marketing campaign,
they'll get a steady stream of attention from academics and press.

I would guess less so from real attackers, because there are easier pickings elsewhere, but maybe
I'm wrong:

"From May to June 2009 the total number of fraudulent website URLs using VeriSign SSL
certificates represented 26% of all SSL certificate attacks, while the previous six months
presented only a single occurrence," Raza wrote on the Symantec Security blogs.
... MarkMonitor found more than 7,300 domains exploited four top U.S. and international bank
brands with 16% of them registered since September 2008.
.... But in the latest spate of phishing attempts, the SSL certificates were legitimate because "they
matched the URL of the fake pages that were mimicking the target brands," Raza wrote.

VeriSign Inc., which sells SSL certificates, points out that SSL certificate fraud currently
represents a tiny percentage of overall phishing attacks. Only two domains, and two VeriSign
certificates were compromised in the attacks identified by Symantec, which targeted seven
different brands.

"This activity falls well within the normal variability you would see on a very infrequent
occurrence," said Tim Callan, a product marketing executive for VeriSign's SSL business unit.
"If these were the results of a coin flip, with heads yielding 1 and tails yielding 0, we wouldn't be
surprised to see this sequence at all, and certainly wouldn't conclude that there's any upward
trend towards heads coming up on the coin."

Well, we hope that nobody's head is flipped in an unsurprising fashion....

It remains to be seen whether this makes any difference. I must admit, I check the green bar on
my browser when online-banking, but annoyingly it makes me click to see who signed it. For
real users, Firefox says that it is the website, and this is wrong and annoying, but Mozilla has not
shown itself adept at understanding the legal and business side of security. I've heard Safari has
been fixed up so probably time to try that again and report sometime.

Then, over to Germany, where a snafu with a HSM ("high security module") caused a root key to
be lost (also in German). Over in the crypto lists, there are PKI opponents pointing out how this
means it doesn't work, and there are PKI proponents pointing out how they should have
employed better consultants. Both sides are right of course, so what to conclude?

Test runs with Germany's first-generation electronic health cards and doctors' "health
professional cards" have suffered a serious setback. After the failure of a hardware security
module (HSM) holding the private keys for the root Certificate Authority (root CA) for the first-
generation cards, it emerged that the data had not been backed up. Consequently, if additional
new cards are required for field testing, all of the cards previously produced for the tests will
have to be replaced, because a new root CA will have to be generated. ... Besides its use in
authentication, the root CA is also important for card withdrawal (the revocation service).

The first thing to realise was that this was a test rollout and not the real thing. So the test
discovered a major weakness; in that sense it is successful, albeit highly embarrassing because it
reached the press.

The second thing is the HSM issue. As we know, PKI is constructed as a hierarchy, or a tree. At
the root of the tree is the root key of course. If this breaks, everything else collapses.

Hence there is a terrible fear of the root breaking. This feeds into the wishes of suppliers of high
security modules, who make hardware that protect the root from being stolen. But, in this case,
the HSM broke, and there was no backup. So a protection for one fear -- theft -- resulted in a
vulnerability to another fear -- data loss.

A moment's thought and we realise that the HSM has to have a backup. Which has to be at least
as good as the HSM. Which means we then have some rather cute conundrums, based on the
Alice in Wonderland concept of having one single root except we need multiple single roots... In
practice, how do we create the root inside the HSM (for security protection) and get it to another
HSM (for recovery protection)?

Serious engineers and architects will be reaching for one word: BRITTLE! And so it is. Yes, it is
possible to do this, but only by breaking the hierarchical principle of PKI itself. It is hard to
break fundamental principles, and the result is that PKI will always be brittle, the
implementations will always have contradictions that are swept under the carpet by the
managers, auditors and salesmen. The PKI design is simply not real world engineering, and the
only thing that keeps it going is the institutional deadly embrace of governments, standards
committees, developers and security companies.

Not the market demand. But, not all has been bad in the PKI world. Actually, since the
bottoming out of the dotcom collapse, certs have been on the uptake, and market demand is
present albeit not anything beyond compliance-driven. Here comes a minor item of success:

VeriSign, Inc. [SNIP] today reported it has topped the 1 billion mark for daily Online Certificate
Status Protocol (OCSP) checks.

[SNIP] A key link in the online security chain, OCSP offers the most timely and efficient way for
Web browsers to determine whether a Secure Sockets Layer (SSL) or user certificate is still valid
or has been revoked. Generally, when a browser initiates an SSL session, OCSP servers receive
a query to check to see if the certificate in use is valid. Likewise, when a user initiates actions
such as smartcard logon, VPN access or Web authentication, OCSP servers check the validity of
the user certificate that is presented. OSCP servers are operated by Certificate Authorities, and
VeriSign is the world's leading Certificate Authority.

[SNIP] VeriSign is the EV SSL Certificate provider of choice for more than 10,000 Internet
domain names, representing 74 percent of the entire EV SSL Certificate market worldwide.

(In the above, I've snipped the self-serving marketing and one blatant misrepresentation.)

Certificates are static statements. They can be revoked, but the old design of downloading
complete lists of all revocations was not really workable (some CAs ship megabyte-sized lists).
We now have a new thing whereby if you are in possession of a certificate, you can do an online
check of its status, called OCSP.

The fundamental problem with this, and the reason why it took the industry so long to get around
to making revocation a real-time thing, is that once you have that architecture in place, you no
longer need certificates. If you know the website, you simply go to a trusted provider and get the
public key. The problem with this approach is that it doesn't allow the CA business to sell
certificates to web site owners. As it lacks any business model for CAs, the CAs will fight it
tooth & nail.

Just another conundrum from the office of security Kafkaism.

Here's another one, this time from the world of code signing. The idea is that updates and plugins
can be sent to you with a digital signature. This means variously that the code is good and won't
hurt you, or someone knows who the attacker is, and you can't hurt him. Whatever it means,
developers put great store in the apparent ability of the digital signature to protect themselves
from something or other.

But it doesn't work with Blackberry users. Allegedly, a Blackberry provider sent a signed code
update to all users in United Arab Emirates:

Yesterday it was reported by various media outlets that a recent BlackBerry software update
from Etisalat (a UAE-based carrier) contained spyware that would intercept emails and text
messages and send copies to a central Etisalat server. We decided to take a look to find out
more.

...
Whenever a message is received on the device, the Recv class first inspects it to determine if it
contains an embedded command — more on this later. If not, it UTF-8 encodes the message,
GZIPs it, AES encrypts it using a static key (”EtisalatIsAProviderForBlackBerry”), and Base64
encodes the result. It then adds this bundle to a transmit queue. The main app polls this queue
every five seconds using a Timer, and when there are items in the queue to transmit, it calls this
function to forward the message to a hardcoded server via HTTP (see below). The call to
http.sendData() simply constructs the POST request and sends it over the wire with the proper
headers.

Oops! A signed spyware from the provider that copies all your private email and sends it to a
server. Sounds simple, but there's a gotcha...

The most alarming part about this whole situation is that people only noticed the malware
because it was draining their batteries. The server receiving the initial registration packets (i.e.
“Here I am, software is installed!”) got overloaded. Devices kept trying to connect every five
seconds to empty the outbound message queue, thereby causing a battery drain. Some people
were reporting on official BlackBerry forums that their batteries were being depleted from full
charge in as little as half an hour.

So, even though the spyware provider had a way to turn it on and off:

It doesn’t seem to execute arbitrary commands, just packages up device information such as
IMEI, IMSI, phone number, etc. and sends it back to the central server, the same way it does for
received messages. It also provides a way to remotely enable/disable the spyware itself using the
commands “start” and “stop”.
There was something wrong with the design, and everyone's blackberry went mad. Two points:
if you want to spy on your own customers, be careful, and test it. Get quality engineers on to that
part, because you are perverting a brittle design, and that is tricky stuff.

Second point. If you want to control a large portion of the population who has these devices, the
centralised hierarchy of PKI and its one root to bind them all principle would seem to be
perfectly designed. Nobody can control it except the center, which puts you in charge. In this
case, the center can use its powerful code-signing abilities to deliver whatever you trust to it.
(You trust what it tells you to trust, of course.)

Which has led some wits to label the CAs as centralised vulnerability partners. Which is odd,
because some organisations that should know better than to outsource the keys to their security
continue to do so.

But who cares, as long as the work flows for the consultants, the committees, the HSM providers
and the CAs?

Posted by iang at July 15, 2009 07:13 AM | TrackBack

I agree that PKI works horribly bad, but mostly for reasons other than those you listed.

You bring up the HSM argument, but in the example you point out the problem is the operational
incompetence, not the HSM per se (which is just a big smartcard, do you hate smartcards too?)
or PKI. It is also questionable to regard the HSM backup as a further root, the main reason being
that such backup won't be for sure another HSM, but rather some caveau in some local banks.

The last argument (the Saudi case), is more related to trust, delegation, accountability and access
control (within your device). I guess that RIM (the root?) gave out a certificate to Etisalat. Which
rights did RIM gave away? Apparently all. Is Etisalat accuntable? Probably, but I'd be curious to
see the contract for the certificate transaction. Is it a problem specific to PKI? I don't think so.

As I mentioned at the beginning, PKI is hideous, but because it is a absurd legacy system, and
because of the fact it is misunderstood, too complex, and poorly documented.

Posted by: Dodecaedro at July 20, 2009 02:30 PM

recent (PKI related) news article thread

Security certificates warnings don't work, researchers say

as mentioned in the above ... ssl domain name digital certificates are redundant and
superfluous ... frequently I've pontificated that most of the PKI-related hype has been to try and
create the impression of a value proposition for the certificates.
original design point for digital certificates are the offline email days of the early 80s ... dial-up
up electronic postoffice, exchange email, hang-up and then faced with authenticating first time
communication with stranger. this is the electronic equivalent of the letters of credit/introduction
from the sailing ship days (when relying party had no other alternative when faced with first time
interaction with complete stranger).

we were called in to consult with small client/server startup that wanted to do payment
transactions on server ... and the startup had invented this technology called "SSL". As part of
that effort, we had to do business and technology walk thrus of the process ... including these
new business operations calling themselves Certification Authorities.

I've frequently pontificated before that in that time-frame IPSEC was having difficulty (because
it required upgrading underlying TCP/IP stacks, upgrading installed software on hundreds of
millions of machines, upgrading underlying infrastructure). In fall '94 IETF meeting, what came
to be called VPN was introduced in gateway committee meeting. My impression was this upset
the IPSEC forces ... who eventually started referring to VPN as light-weight IPSEC (and gave
the VPN folks the opportunity to refer to IPSEC as heavy-weight IPSEC).

The uptake of both VPN and SSL (in same time-frame) was because they didn't require any hits
to underlying infrastructure ... in SSL case, it was purely new webserver software and new
browser software (pure addon, w/o changes to existing legacy infrastructure).

The eventual problem (at least for SSL) is it layers a whole bunch of (technology and business
operation) gorp on top of the underlying infrastructure ... that is much better integrated
(seamlessly) into the underlying infrastructure (eliminating huge expense and complexity of
duplicated operations). As SSL becomes pervasive ... the trade-offs change regarding the
simplicity of adding something on-top verses seamless integration into the underlying
infrastructure.

The SSL (PKI) security scenario is similar to lots of other security issues regarding the ease of
adding something ontop (eventually creating huge complex patchwork) versus building security
(seamlessly) into the basic design and implementation.

for a little other topic drift ... at '92 annual SIGMOD conference ... somebody raised the question
about what was all this "x.5**" stuff about ... and somebody in the audience stated it was
networking engineers attempting to reinvent 1960s database technology. some related posts:
http://www.garlic.com/~lynn/2009k.html#29 Oracle Database Abandons z/OS
and
http://www.garlic.com/~lynn/2008p.html#27 Father of Financial Dataprocessing

lots of past posts mentioning SSL digital certificates

and lots of past posts mentioning certificate-less public key operation

He he, ties right into the Symbian-signed mobile trojans news piece at El Reg..
http://www.theregister.co.uk/2009/07/23/sms_worm_analysis/

Quote

"Symbian reacted promptly to revoke these certificates. Handsets do not automatically check for
these revocations, however. F-Secure warns: "The default setting in most Symbian phones has to
be changed to enable them to receive revocation certificates. To do this, go to Application
Manager's Settings and set the Online certificate check to Must be passed"."

Posted by: AC2 at July 31, 2009 04:17 AM

Black Hat: SSL is fragile

from above:

Researchers at the Black Hat security conference in Las Vegas have proved that the Secure
Sockets Layer (SSL) protocol is fragile and could be broken at any time.

... snip ...

Note that we were brought in to consult with this small client/server startup that wanted to do
payment transactions on their server and the startup had invented this technology called "SSL".
As part of use for payment transactions, we had to do some end-to-end investigations of how the
technology was being used and various business processes ... included some of this new
operations calling themselves Certification Authorities. Part of the issue was that there were
some specific requirements regarding how it was deployed ... which were almost immediately
violated. That was one of the things that prompted us to coin the term "comfort certificates".

Posted by: Lynn Wheeler at July 31, 2009 08:35 AM

URL got truncated

Posted by: Lynn Wheeler at July 31, 2009 09:19 AM

Get a load of this.

OTHERWISE, ALL YOUR MONEY ARE BELONG TO US!!!111!!!

Posted by: Anonymous at August 5, 2009 11:40 PM

But discussing it is a bit like asking Nero to retune his fiddle, it's not going to stop the flames
from spreading. with little doubt most security solutions are aimed at the wrong place in the
wrong way and as such are a "bonfire of the vanities".

The real security issue which is being ignored is also the reason we use DOD TCP/IP not ISO
OSI protocols and it's "pragmatism" and it's flip side "efficiency".

People need to get things done and in all honesty they care not how it is done just that it has the
illusion of answering a need at a specific point of time within the available resources.

Due to various things the amount of data people want to move around appears to double about
every 10 months, however it tends to hit the end stops of technology frequently enough to
prevent the wished for target.

As long as there is a technology limitation and a market desire to go beyond it then pragmatism
will win hands down every time.

Unfortunately pragmatism and security are usually not good bedfellows. Pragmatism is a
business issue security a technical issue take a guess which one is going to win in a "free market
economy".

Part of the issue is "efficiency -v- security", the more efficient a system the more it is susceptible
to opening up side channels that leak information to those that know how to see it. Unless certain
very fundamental steps are taken a system will always be vulnerable to "efficiency security
weakness".

As an example unless a system designer clocks both the data in and the data out of a system then
no matter how secure the OS the apps etc are a user can by exploiting simple timing attacks open
up a side channel right through it (and even if the data is clocked synchronously there are a few
other things that need doing as well).

With only moderately more work the side channel can be made covert enough that it is unlikely
to be detected (ie below the "threshold of detection").

IPSec is not going to stop this and nor are most other security systems currently waiting in the
wings.

So it does not really matter at what level above the real foundations (base hardware) of the
system you put in security it is going to be possible to bypass it with a side channel that with
only moderate work can be made covert to the point of invisibility.
The only real issue is the amount of bandwidth in the channel, the less there is the harder it is to
spot the channel. But ask yourself the question just how much bandwidth do you need to leak a
session key?