July 15, 2009

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
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

Posted by: Lynn Wheeler at July 28, 2009 11:48 AM

He he, ties right into the Symbian-signed mobile trojans news piece at El Reg..


"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.


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

There are a whole load of things wrong with SSL and CA's certainly enough to fill a couple of books.

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?

Posted by: Clive Robinson at August 9, 2009 07:50 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.