Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> > and MD5 is definitely _NOT_ suitable
> > for anything with the term "integrity" in it.
> 
> That depends imo on whether "integrity" is used as a term in a security
> context by a security person, or by anyone else. (I am not using the
> term as a security person, but have been forced to use it when talking to
> security people who have little notion of protection against errors or of
> reliability.)
> 
> 
> > Integrity protection is terminology that is used in the
> > security&cryptographic area and this defect of rfc-4270 is going
> > to create misunderstandings.
> 
> Yes.
> 
> We've actually run into this problem previously, and had to carefully use the
> terms when talking to those who focus on terminology used, rather than the
> overall point that is trying to be made. This leads to verbal gyrations
> and a degree of doubletalk.
> 
> 'Integrity' and 'protection' do have meanings outside security, and were used
> long before their specific use in a security context (cf database integrity,
> system integrity, even integrity protection in chemical plants). From context
> here and the rest of the sentence, it's imo clear that reliability is what
> is being referred to.


I've been focused so much on security over more than a decade that
myself I am actually unfamiliar with uses of "integrity protection"
in a sense that is _not_ security-related.


Although the attacks against MD5 published so far are practical only
for creating collision pairs, there has not been published a practical
preimage attack against MD5.  But the practical collision attack alone
is devastating for several integrity protection usage scenarios.

   see this here: http://www.win.tue.nl/hashclash/rogue-ca/

Open the "Certificate Manager" of a newer Firefox/Mozilla browser
(Menu:  Tools->Options, Section "Advanced", Tab "Encryption",
 Button "View Certificates", Tab "Authorities")

Under "Equifax Secure Inc." you will probably find a CA certificate
labelled "MD5 Collisions Inc. (http://www.phreedom.org/md5)"
signed by Equifax Secure Global eBusiness CA-1, expired in Sep-2004
and that cert is pre-configured to be _not_ trusted for any purpose.
(a somewhat non-obvious way of blacklisting a certificate).

The MD5-based RSA signature in that cert still contains the original
MD5 checksum that Equifax calculated when it issued a different
(but fairly similar) end-entity cert with a different validity.


This fake CA certificate was created with the help of the MD5 collision
attack, not by a preimage attack.

But if you look at the purpose / usage scenario of the MD5 hash here,
then it is about some SSL client ("Bob") receiving an assertion of identity
for a server "i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org"
integrity protected by an RSA-encrypted MD5 hash from Equifax ("Alice"),
which can be successfully substitued by an attacker ("mallory") with
an intermediate CA certificate (plus an end-entity cert for any arbitrary
server created at will by mallory), and the Equifax-signed
MD5 checksum does not protect against this substitution, because
the fake CA cert has the exact same MD5 checksum as the cert
originally issued by Equifax.

The details are described in section 5.3 (but only 5.2 has an anchor tag):

   http://www.win.tue.nl/hashclash/rogue-ca/#sec52


Admittedly it isn't trivial to use a collision attack to do achieve
something that normally requires a preimage attack, but it is going to
be possible much more often than you will want it to for a creative
attacker.  And a lot of PDUs that are digitally signed these days
provide wiggle room for "binary random stuffing" necessary to precompute
collision attacks and will be ignored by recipients.  Especially in
protocols using ASN.1.

According to this report:

  http://www.eff.org/files/DefconSSLiverse.pdf

there appear to exist almost 1500 "trustworthy" SSL CAs, and
and attacker only needs to find a single one among them where
such an attack still works...


-Martin