[17054] in cryptography@c2.net mail archive
RE: Colliding X.509 Certificates
daemon@ATHENA.MIT.EDU (Weger, B.M.M. de)
Sun Mar 13 14:44:37 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Fri, 11 Mar 2005 12:11:35 +0100
From: "Weger, B.M.M. de" <b.m.m.d.weger@TUE.nl>
To: "Joerg Schneider" <js@joergschneider.com>,
"Olle Mulmo" <mulmo@pdc.kth.se>
Cc: <cryptography@metzdowd.com>
Hi Joerg,
It's true that our 'attack' assumes that the attacker has sufficient
control over the CA, in particular over setting DN's, serial numbers=20
and the validity period. Yet I have a few remarks on this.
A relying party cannot find out from the certificate alone whether
it has a "twin sister" or not. The fact that there is a random-looking
serial number doesn't help you there.
A newly issued certificate based on MD5 should not be trusted anymore=20
anyway. The only reasonable measure against collision-based attacks is=20
to declare MD5 dead. It's better to bury it than to try keeping it =
alive.
I have nothing against randomized serial numbers. But your security=20
should be based on better ideas. And it's just as easy to avoid broken=20
hash functions.
Grtz,
Benne de Weger
> -----Original Message-----
> From: Joerg Schneider [mailto:js@joergschneider.com]=20
> Sent: vrijdag 11 maart 2005 11:52
> To: Olle Mulmo
> Cc: Weger, B.M.M. de; cryptography@metzdowd.com
> Subject: Re: Colliding X.509 Certificates
>=20
> Olle Mulmo wrote:
> > Seems to me that a CA can nullify this attack by choosing a serial=20
> number or RDN component (after all, a CA should vet the DN and not=20
> simply sign what's in the PKCS#10 request), such that the public key=20
> does not end up at an "appropriate" DER-encoded offset in the
> > certificate. Or am I completely lost?
>=20
> Yes, there seem to several possibilities to defend against=20
> this kind of=20
> attack in a real world scenario. Modifying the subject DN in a way
> un-predictable by the attacker is one of them. For Benne's=20
> attack it would
> be enough to modify its length, so that the public key=20
> doesn't get to the
> required offset.
>=20
> I would like to have a general way to fend off collision attacks on
> certificates. To this end I propose that the CA generates the=20
> certificate
> serialNumber in a way that cannot be guessed. Some CAs are=20
> already doing
> this, I guess mainly to prevent people from seeing how many certs they
> issue.
>=20
> There are several advantages of using the serialNumber:
> * it has no semantics that we might break, as long as we make sure it
> stays unique
> * it is one of the first items in a certificates, before any=20
> content an
> attacker might control
> * its no problem to make it e.g. 128 bits long
>=20
> By putting an un-guessable value in the serialNumber, the attacker is
> faced with a similar problem as with a HMAC, which people=20
> believe are not
> affected by the known collision attacks. For this reason I=20
> believe with
> un-guessable serialNumbers, we should be safe to use a hash function,
> which is not collision resistant, as long as it is 2nd pre-image
> resistant.
>=20
> Its rather easy to implement un-guessable servialNumbers:
> * use a cryptographically strong PRNG (and keep the seed=20
> secret) or TRNG
> * encrypt a counter with a block cipher (and keep the key secret)
>=20
> Best regards,
>=20
> J=F6rg
>=20
>=20
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
