[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