Colliding X.509 Certificates

[Joerg Schneider]

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