Colliding X.509 Certificates

[Weger, B.M.M. de]

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 
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 
anyway. The only reasonable measure against collision-based attacks is 
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 
should be based on better ideas. And it's just as easy to avoid broken 
hash functions.

Grtz,
Benne de Weger

> -----Original Message-----
> From: Joerg Schneider [mailto:js at joergschneider.com] 
> Sent: vrijdag 11 maart 2005 11:52
> To: Olle Mulmo
> Cc: Weger, B.M.M. de; cryptography at metzdowd.com
> Subject: Re: Colliding X.509 Certificates
> 
> Olle Mulmo wrote:
> > Seems to me that a CA can nullify this attack by choosing a serial 
> number or RDN component (after all, a CA should vet the DN and not 
> simply sign what's in the PKCS#10 request), such that the public key 
> does not end up at an "appropriate" DER-encoded offset in the
> > certificate. Or am I completely lost?
> 
> Yes, there seem to several possibilities to defend against 
> this kind of 
> 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 
> attack it would
> be enough to modify its length, so that the public key 
> doesn't get to the
> required offset.
> 
> 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 
> certificate
> serialNumber in a way that cannot be guessed. Some CAs are 
> already doing
> this, I guess mainly to prevent people from seeing how many certs they
> issue.
> 
> 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 
> content an
> attacker might control
> * its no problem to make it e.g. 128 bits long
> 
> By putting an un-guessable value in the serialNumber, the attacker is
> faced with a similar problem as with a HMAC, which people 
> believe are not
> affected by the known collision attacks. For this reason I 
> 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.
> 
> Its rather easy to implement un-guessable servialNumbers:
> * use a cryptographically strong PRNG (and keep the seed 
> secret) or TRNG
> * encrypt a counter with a block cipher (and keep the key secret)
> 
> Best regards,
> 
> Jörg
> 
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com