headers
Peter Gutmann | 1 Jan 2009 12:11
Picon
Picon
Picon
Favicon

Re: [saag] Further MD5 breaks: Creating a rogue CAcertificate

"Santosh Chokhani" <SChokhani <at> cygnacom.com> writes:

>We are simply not vigilant enough.  This issue has been on our plate since
>2004.

It's not just this, the fact that there were CA certs out there with the CA
flag (in basicConstraints) not set was known for at least five years before
widespread bad publicity forced CAs to address it, the RSA exponent=1 debacle
was known for at least that long but no-one cared until there was lots of bad
publicity about it... there's a really serious problem with CAs and vendors
simply not caring about PKI security until bad publicity forces a change, the
curent MD5 issue (and the mozilla.com cert debacle and the Gromozon malware-
signing cert issue and ...) are just the latest examples.  It's like the
Microsoft of ten years ago, security holes just get ignored until bad
publicity forces a fix (and even then it's often more of a sidestep to avoid
further criticism than an actual fix).

It's small wonder that there's such widespread cynicism about PKI when even
the organisations pushing it don't seem to care whether it's done properly or
not.

Peter.
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 1 Jan 2009 12:17
Picon
Picon
Picon
Favicon

Re: [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

Mike <mike-list <at> pobox.com> writes:

>> We are simply not vigilant enough.  This issue has been on our plate
>> since 2004.
>>
>> SHA-1 is next and neither the client side vendors nor the big
>> Enterprises have pushed to move to SHA-256.
>
>There is a simple fix -- a CA can just reorder the extensions prior to
>issuing a certificate.

That's actually a nice fix, but unfortunately not universally applicable: for
some types of signed data (e.g. S/MIME attributes) the DER rules require
sorting the encoded extensions, so there's only one valid order for them (and
some applications actually check for this, so you have to do it or sig checks
will start failing).

Peter.
Permalink | Reply | 0 comments |
headers
Santosh Chokhani | 1 Jan 2009 12:39
Favicon

Re: [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

Also, for the actual attack, the ordering of extensions will not work as
long as the certificate size does not change.  If you look at the actual
attack, collision block in the real certificate is up to the SPKI.  The
extension values from the real certificate are simply copied in the
tumor of the rogue certificate.

Given the property that if H(M) = H (M') then H(M | X) = H (M' | X), the
attacker simply copies the extensions from actual certificate in the
tumor.

-----Original Message-----
From: saag-bounces <at> ietf.org [mailto:saag-bounces <at> ietf.org] On Behalf Of
Peter Gutmann
Sent: Thursday, January 01, 2009 6:18 AM
To: ietf-pkix <at> imc.org; mike-list <at> pobox.com
Cc: ietf-smime <at> imc.org; cfrg <at> irtf.org; saag <at> ietf.org
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate

Mike <mike-list <at> pobox.com> writes:

>> We are simply not vigilant enough.  This issue has been on our plate
>> since 2004.
>>
>> SHA-1 is next and neither the client side vendors nor the big
>> Enterprises have pushed to move to SHA-256.
>
>There is a simple fix -- a CA can just reorder the extensions prior to
>issuing a certificate.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eygene Ryabinkin | 1 Jan 2009 12:42
Picon

Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate


David,

Wed, Dec 31, 2008 at 04:49:02PM -0500, David A. Cooper wrote:
> You are correct that a change anywhere in the certificate will change
> the hash.  However, the attacker does not need to know in advance what
> the hash value will be, only that the hash of the real certificate and
> the rogue certificate will be the same. If you look at the image
> depicting the generation of the collision in the attack
> (http://www.win.tue.nl/hashclash/rogue-ca/downloads/alignment.pdf), you
> will see why these two statements are not the same.

Yes, now I am starting to get the meaning of the "chosen prefix" ;))

Thanks a lot!
--

-- 
Eygene Ryabinkin, Russian Research Centre "Kurchatov Institute"
Permalink | Reply | 0 comments |
headers
Ben Laurie | 1 Jan 2009 16:06
Picon
Favicon

Re: [saag] Further MD5 breaks: Creating a rogue CAcertificate

On Thu, Jan 1, 2009 at 11:17 AM, Peter Gutmann
<pgut001 <at> cs.auckland.ac.nz> wrote:
>
> Mike <mike-list <at> pobox.com> writes:
> >There is a simple fix -- a CA can just reorder the extensions prior to
> >issuing a certificate.
>
> That's actually a nice fix, but unfortunately not universally applicable: for
> some types of signed data (e.g. S/MIME attributes) the DER rules require
> sorting the encoded extensions, so there's only one valid order for them (and
> some applications actually check for this, so you have to do it or sig checks
> will start failing).

Surely the whole point of DER is that there's only one correct way to
encode any particular certificate?

So, either extensions must be sorted, or changing their order changes
their meaning. Either way, nothing can be reordered.
Permalink | Reply | 0 comments |
headers
Santosh Chokhani | 1 Jan 2009 16:14
Favicon

RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate


Changing the order of extensions does not change their meaning.

Actually, a CA could put the extensions in random order for various
certificates.  The attack will still work if the certificate size does
not change.

-----Original Message-----
From: cfrg-bounces <at> irtf.org [mailto:cfrg-bounces <at> irtf.org] On Behalf Of
Ben Laurie
Sent: Thursday, January 01, 2009 10:06 AM
To: Peter Gutmann
Cc: ietf-pkix <at> imc.org; mike-list <at> pobox.com; cfrg <at> irtf.org;
saag <at> ietf.org; ietf-smime <at> imc.org
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

On Thu, Jan 1, 2009 at 11:17 AM, Peter Gutmann
<pgut001 <at> cs.auckland.ac.nz> wrote:
>
> Mike <mike-list <at> pobox.com> writes:
> >There is a simple fix -- a CA can just reorder the extensions prior
to
> >issuing a certificate.
>
> That's actually a nice fix, but unfortunately not universally
applicable: for
> some types of signed data (e.g. S/MIME attributes) the DER rules
require
> sorting the encoded extensions, so there's only one valid order for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike | 1 Jan 2009 16:51
Picon
Favicon

Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate


Is there anything that could be added to RP software to reliably
detect and thwart the use of a rogue CA certificate?  Or would
any attempt to do that just cause too many problems?

Mike (who is writing "I am not a security expert" 100 times on
       the chalkboard)
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 1 Jan 2009 18:07

Re: [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

At Thu, 01 Jan 2009 07:51:38 -0800,
Mike wrote:
> 
> 
> Is there anything that could be added to RP software to reliably
> detect and thwart the use of a rogue CA certificate?  Or would
> any attempt to do that just cause too many problems?
> 
> Mike (who is writing "I am not a security expert" 100 times on
>        the chalkboard)

You could certainly add a check for this particular certificate
and any others you discovered. To the extent to which CAs no 
longer use MD5, this would likely quickly clean up the damage.
It's less clear that you could safely detect this kind of
cert in a generic way.

-Ekr
Permalink | Reply | 0 comments |
headers
Paul Hoffman | 1 Jan 2009 18:20

Re: [saag] Further MD5 breaks: Creating a rogue CAcertificate

At 3:06 PM +0000 1/1/09, Ben Laurie wrote:
>Surely the whole point of DER is that there's only one correct way to
>encode any particular certificate?

Not so "surely". The SEQUENCE for extensions does not say what order they should be in.

>So, either extensions must be sorted, or changing their order changes
>their meaning. Either way, nothing can be reordered.

Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order.

However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper.

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 0 comments |
headers
Ben Laurie | 1 Jan 2009 18:44

Re: [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

Paul Hoffman wrote:
> At 3:06 PM +0000 1/1/09, Ben Laurie wrote:
>> Surely the whole point of DER is that there's only one correct way to
>> encode any particular certificate?
> 
> Not so "surely". The SEQUENCE for extensions does not say what order they should be in.

That doesn't change the _point_ of DER. If extensions should have been
specified as a SET but are defined as a SEQUENCE, then they are broken
(technically).

>> So, either extensions must be sorted, or changing their order changes
>> their meaning. Either way, nothing can be reordered.
> 
> Wrong on both counts. Each extension has stand-alone semantics, and they can be in any order.

My point was about the correct use of DER. It seems extensions use it
incorrectly.

> However, this is irrelevant for the MD5 break discussion, as is clearly shown in the paper.

I am discussing the correct use of DER :-)

--

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Permalink | Reply | 0 comments |

Gmane