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

[Larry Seltzer]

Incidentally, DigiNotar has declared bankruptcy:
http://www.vasco.com/company/press_room/news_archive/2011/news_vasco_announces_bankruptcy_filing_by_diginotar_bv.aspx

LJS

On Tue, Sep 20, 2011 at 4:56 AM, Rob Stradling <rob.stradling at comodo.com>wrote:

> This year, we've seen 2 types of approach to revocation:
>
> 1. "Normal" revocation (CRLs and OCSP Responses published by the CAs).
> 2. "Emergency" revocation (Certificate Blacklists published by the
> Browsers).
>
> Comodo-gate: All 9 of the mis-issued certificates were promptly marked as
> "revoked" in CRLs and in OCSP Responses within a few hours of being issued.
> All of the attacker's movements were sufficiently logged, resulting in the
> CA
> being confident that no other certificates were mis-issued to the attacker.
>  The
> compromised application-level account was quickly suspended.  The incident
> was
> disclosed to the major Browser Vendors promptly.
> In short: The CA regained control, the CA didn't lose the trust of the
> Browser
> Vendors, and "Normal" revocation should have been enough to ensure that
> end-
> users were not left vulnerable to MITM attacks.
> But instead, the Browser Vendors had to resort to "Emergency" revocation
> because the "Normal" revocation mechanisms could have been subverted by the
> attacker in various different ways.
>
> DigiNotar-gate: Numerous certificates were mis-issued, not promptly
> detected
> and not promptly marked as "revoked" in CRLs and in OCSP Responses.  The CA
> failed to log what happened, failed to disclose the incident for many
> weeks,
> and couldn't be sure that they'd identified every cert that the attacker
> had
> mis-issued.
> In short: The CA completely lost control, lost the trust of the Browser
> Vendors, and relying on "Normal" revocation would've been like rearranging
> deckchairs on the Titanic.  "Emergency" revocation was absolutely
> necessary.
>
> So I think we need both types of revocation, but they both need to work
> better
> than they currently do.
> "Normal" revocation needs to be improved so that it is sufficient in cases
> where
> the CA regains control.
> "Emergency" revocation needs a more coordinated, scalable approach.  (See
> [1]
> for some thoughts from PHB and me).
>
> On Friday 16 Sep 2011 09:28:56 Peter Gutmann wrote:
> <snip>
> > For example given that an attacker who compromises a CA can add their own
> > AIA to the fraudulent certs it mints that point to an attacker-controlled
> > responder with another fraudulent cert that "authenticates" any response
> (or
> > simply leave out the AIA, so there's no responder to check), it doesn't
> > matter what the rest of the infrastructure does.
>
> Perhaps this would be classed as a scenario from which the CA cannot regain
> control.  And if so, it wouldn't be a problem that "Normal" revocation
> would
> need to consider.
>
> <snip>
> > I would really like to see a proper threat model for this.
>
> I realize I probably haven't achieved that with this post.
>
> > What are we defending against?
>
> State-level attackers.  And we should expect them to persist in their
> efforts.
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=685286 (the "Proposal for
> establishing an emergency response format based on OCSP and DNS/CAA"
> attachment)
>
>
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20110920/643a9648/attachment.html>