1
$\begingroup$

Papers from Marc Stevens et al show that X509 certificates that rely on MD5 signatures can break the assumed security model, that is, it allows for a forged certificate to have the same signature as a trusted cert, see https://marc-stevens.nl/research for these papers. Both methods require the "to be signed" portion of the certificate to be known in order for the collision search to begin. Both require some "control" over the CA, whether it is by setting a fake CA or correctly predicting the validity and serial fields.

My question is why is this necessary? I understand that I need to know the to be signed parts, but why can't I just get this information from an already generated cert? I must be missing something simple about how these certs are constructed.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

The reason for this is because it is impossible to generate an MD5 for just any $y$, where $y$ is the output of any $x$ that isn't pre-computed. MD5 is broken but it is not completely broken. Using the common terms, MD5 is broken with regards to collision attacks, but not broken with regards to pre-image attacks.

So your assumption that "Both methods require the "to be signed" portion of the certificate to be known" is not strong enough; a block (or two) in the to-be-signed portion should be pre-computed.

The to be signed portion is usually send to the CA in a certificate request. The CA uses the information in the certificate request and creates and signs the certificate that contains the information from the certificate request. This is usually automated, so if you can get past some filters you will be send the resulting certificate. At this point you can create a certificate that contains different information by altering the pre-computed block to create the correct MD5. Because the MD5 hash doesn't change the signature remains valid.

So the attack that's most potent is to pre-generate a certificate request for *.kzs8wf.com and a certain crafted public key forming the pre-computed block. You then receive the resulting certificate and then modify it to a *.google.com certificate with an re-calculated public key forming the altered pre-computed block.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Darn, I wish I still had the two script files with identical MD5. Stupid company virusscanner threw them away. It was perfect demonstrational material. $\endgroup$
    – Maarten Bodewes ♦
    Nov 29, 2015 at 12:05
  • $\begingroup$ Thank you very much. I believe I wasn't reading the construction carefully. I didn't realize until after reading your comment that both certificate requests require birthdaying bits (collision attack). I somehow thought we only needed info from the 1st cert to construct the 2nd (which would be a preimage attack). $\endgroup$
    – andy
    Nov 29, 2015 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.