[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sat Sep 3 23:15:32 PDT 2011


[Sent to three lists from which input would be useful, please trim followups
 if you feel it's off-topic]

I was reading through the various summaries of the Diginotar broken arrow 
yesterday and realised that it's a pretty comprehensive tour de force of every 
piece of PKI brokenness that people have been warning about for the past ten 
to fifteen years.  Almost everything in it would have been entirely avoidable 
if PKI were less driven by religious dogma and more by good, solid security 
engineering.  Here are some of the cases that spring to mind:

Blacklist-based validity checking, the Second Dumbest Idea in Computer
Security (Marcus Ranum), doesn't work: 

  Diginotar issued certs for which there was no record of issuance, therefore
  they couldn't be revoked.  Whitelist-based checking would have prevented
  this.
  
  (This one really is pretty incredible, PKI relies on the *second dumbest
  idea in computer security* for it's "security", and since that's just a 
  variant of the dumbest idea, default-allow, it could be argued that it
  actually relies on the dumbest idea in computer security).

Universal implicit cross-certification makes the entire system as weak as the
weakest link:

  Diginotar apparently issued certs for other majors CAs like Equifax, Thawte,
  and VeriSign, allowing them to usurp other major CAs.

Storing your private key in a dumb hardware device only provides epsilon
increase in actual security:

  An HSM or smart card that does anything the PC that it's attached to tells
  it to is only slightly more secure than simply storing the key directly on
  the PC.  You need to do more to secure a high-value signing process than
  sprinkling smart card/HSM pixie dust around and declaring victory.

Lack of breach disclosure requirements for CAs means that they'll cover
problems up if they can get away with it:

  Diginotar actively covered up, and later downplayed, the magnitude of the
  compromise.  They were only discovered because the certs were publicly used
  on a (large?) scale against victims.  Who knows how many other CAs have been
  compromised, but the public never noticed because the attackers were more
  circumspect and the CAs covered it up.

  (Unlike the other issues, which people had been pointing out repeatedly for
  one- to one-and-a-half decades, this one is relatively new and based on
  recent experience with other CAs' non-disclosure of problems).

Browser PKI is *the* point of security failure for browsers:

  Browsers do absolutely nothing (apart from a token, mostly ineffective site-
  blacklist check) to protect users beyond popping up a warning if the site
  owner didn't pay a CA for their cert.  Once this sole mechanism fails,
  there's nothing protecting the user.  Even the most trivial checks by
  browsers would have caught the fake Google wildcard cert that started all
  this.

OK, so PKI failed again, no harm done, the banks will reimburse you for card
fraud:

  In this case it was more than just that, it appears to have been used by a
  very oppressive regime against its own citizens.  As the SANS diary says,
  "If you're a user in Iran, and had something to hide from your government,
  odds are you're in trouble with your government".

The browser trusted-root formula of "pass an audit, welcome to the gravy
train, please take a seat at the trough" doesn't work in terms of providing
security:

  Diginotar both passed audits in order to get on the browser gravy train and
  then passed a second level of auditing after the compromise was discovered.
  The auditors somehow missed that fact that the Diginotar site showed a two-
  year history of compromise by multiple hacking groups, something that a
  bunch of random commentators on blogs had no problem finding.

There is no escape:

  Unlike many other aspects of security where you can choose not to use option
  A if it fails but switch to option B, with browser PKI there is no option B.
  Browser vendors have chosen to make PKI the only web-site security option
  available.  There is no fallback.  Site owners who are concerned about the
  security of their users can't do anything, because the browser vendors have
  chosen to prevent them from employing any other option (I can't, for
  example, turn on TLS-PSK or TLS-SRP in my server, because no browsers
  support it - it would make the CAs look bad if it were deployed).

Are there any more that I missed?

(A bit less than ninety-five theses, sorry.  In any case there's no door I can
easily nail them to).

Peter.



More information about the Observatory mailing list