Crypto flaw + bad practices = need for governance

Speaking of issues of governance, the Register just brought us this report on a recent “archeological investigation” by Ben Laurie and Richard Clayton that revealed how a Linux security flaw left a number of OpenID sites vulnerable to attack:

“Slipshod cryptographic housekeeping left some OpenID services far less secure than they ought to be.

“OpenID is a shared identity service that enables users to eliminate the need for punters to create separate IDs and logins for websites that support the service. A growing number of around 9,000 websites support the decentralised service, which offers a a URL-based system for single sign-on.

“Security researchers discovered the websites run by three OpenID providers – including Sun Microsystems – used SSL certificates with weak crypto keys. Instead of being generated from billions of possibilities, the keys came from a a set of just 32,768 options, due to a flaw in the random number generation routines used by Debian. The bug, which has been dormant on systems for 18 months, was discovered and corrected back in May.

“Keys generated by cryptographically flawed systems still needed to be replaced even after the software was upgraded. But recent research by Ben Laurie of Google reveals that 1.5 per cent of certificates he looked at contained weak keys. Three OpenID providers (openid.sun.com, xopenid.net and openid.net.nz) were among the guilty parties.

“To exploit the vulnerability, malicious hackers would need to trick surfers into visiting a site impersonating a pukka OpenID provider. But faking digital certificate alone wouldn't do the trick without first misdirecting surfers to these bogus sites. Dan Kaminsky's recent discovery of a DNS cache poisoning flaw made it far more plausible to construct an attack that sent surfers the wrong away around the net's address lookup system, potentially to a bogus Open site posing as the real deal.

“The security flaw meant that even cautious users who check SSL certificates were at risk of handing over their OpenID credentials as part of a phishing attack. Such an attack would take a lot of effort to pull off and would only yield OpenID login credentials, which aren't especially useful for hackers and are difficult to monetise.

“Going after online banking credentials via a site that makes no attempt to offer up fake SSL certificates is a far more reliable moneyspinner, a factor that leads noted security researcher Richard Clayton to describe the attack as the “modern equivalent of a small earthquake in Chile”.

“Sun has responded to the issue by generating a new secure key, which reduces the scope for mischief but still leaves potential problems from the old key.

“More thoughts on the cryptographically interesting – though not especially life-threatening – flaw can be found in Clayton's posting on Cambridge University's Light the Blue Touchpaper blog here. A security advisory by Laurie and Clayton explaining the issue in greater depth can be found here.”

I tip my hat to Ben and Richard for doing what I think of as “system archeology” – looking into the systems people actually leave behind them, as opposed to the ones they think they have built.  We need a lot more of this.  In fact, we need to have full time archeologists rigorously exploring what is being deployed.

This said, I have to question the surprisingly opportunistic title of Richard's piece:  An insecurity in OpenID, not many dead.

Let's get real.  None of what went wrong here was in any way specific to OpenID.  The weakness would have struck any application that relied on crypto and was built on Debian Linux and operated in the same way.  This includes SSL, which for some reason doesn't get singled out.  And it applies to SAML, WS-Trust and PKI  (e.g. any of the security-based identity protocols).  Is OpenID a convenient straw man? 

In fact there were really two culprits.  First, the crypto flaw itself, a problem in Linux.  Second, the fact that although the flaw had been fixed, new keys and certificates had not been obtained by a number of the operators. 

So we are brought right back to the issue of governance, and in all fairness, Richard makes that point too.  Given the improper operating practices, and the fact that OpenID imples no contractual agreement, how would anyone have been able to sort out liability if the flaw had resulted in a serious breach?

Clearly, timely patching of one's operating system needs to be one of the host of requirements placed on any identity provider.  A system of governance would make this explicit, and provide a framework for assigning liability should the requirement not be met.  I really think we need to move forward on a broadly inclusive governance conversation.

And finally, just so no one thinks I have gone out of character, let's all note that any user who employed an Information Card to authenticate to the OpenID provider would NOT have had her credentials stolen, in spite of the vulnerability Ben and Richard have documented.   

 

Published by

Kim Cameron

Work on identity.

One thought on “Crypto flaw + bad practices = need for governance”

  1. There is no mechanism in place for informing applications that relied on older (possibly vulnerable) cryptographic implementations that they need to destroy the keys that they have generated. EVERYTHING that openssl links to or plays a part in — openssh, openid, apache among others — needs to regenerate its persistent keys.

    Cryptography is always a “hindsight is clearer than foresight” art/science. That's not just on the mathematical underpinnings but also on the systemic implementation; we have just had the fog lifted that we will always need a mechanism to notify dependent applications of security issues.

    Windows isn't so bad — a new version of the cryptoAPI provider could request revocation of everything it touches in the store, and can even override the lack of CA revocation by simply preventing the use of the keys in question. The same is true for any cryptographic module which keeps the keys inside its own boundary. So, really, this comes down to “management style” and “management interface”, not just on an application level but also from a complete system-design standpoint.

Comments are closed.