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

James A. Donald jamesd at echeque.com
Sun Sep 4 05:07:36 EDT 2011


On 2011-09-04 4:15 PM, Peter Gutmann wrote:
> [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).

In addition to TLS-SRP we also need yurls - note that Tor does support 
yurls, but Tor is inefficient by design, hence unsuitable for routine use.

If browsers and servers supported TLS-SRP, this would set in motion a 
cascade, as the highest security cases, the people most under attack, 
would switch to SRP, and in due course every logon would become SRP, 
much as minority use of ssh eventually led to everyone using ssh, 
rendering certificates irrelevant except for introduction.  SRP plus 
yurls would render them entirely irrelevant.

It appears to me that SSH came to dominate telnet, because the highest 
security cases had no choice but to use SSH, so everyone wound up 
needing an SSH client, and once everyone had an SSH client ....

I think the same would ensue if we had yurls plus SRP.



More information about the cryptography mailing list