Month: December 2008

Forged CA cert talk at 25C3

~ Nate Lawson ~ 3 Comments

A talk entitled “MD5 considered harmful today” (slides) is being presented at 25C3. The authors describe forging a CA cert that will be accepted by all browsers by exploiting the fact that several trusted root CAs sign certs with MD5. This allows them to spoof their identity as any SSL-enabled website on the Internet, and it will look perfectly valid to the user.

The growth of trusted root CAs included in standard browsers has been an issue for a while. Every root CA is equal in the eyes of the browser, thus the end-user’s security is equivalent to the security of the weakest root CA. The default Firefox install will accept a Yahoo cert signed by “TurkTrust”, or any other of more than 100 root certs. I don’t know how good each of those companies are at securing their keys, implementing strict cert chain validation, and checking the identity of every submitter. So, it’s a good bet that putting crypto authority in the hands of that many people will result in some failures, repeatedly.

The attack is interesting since they take advantage of more than one flaw in a CA. First, they find a CA that still uses MD5 for signing certs. MD5 has been broken for years, and no CA should have been doing this. Next, they prepared an innocent-looking cert request containing the “magic values” necessary to cause an MD5 collision. They were able to do this because of a second flaw. The CA in question used an incrementing serial number instead of a random one. Since the serial is part of the signed data, it is a cheap way to get some randomness. This would have thwarted this particular attack until a pre-image vulnerability was found in MD5. Don’t count on this for security! MD4 fell to a second pre-image attack a few years after the first collision attacks, and attacks only get better over time.

This talk definitely points out that crypto attacks are not being addressed quickly enough in the real world. While it is difficult to roll out a new root CA cert, it’s better to do so over the years we have known MD5 to be insecure than in a rush after an attack has already occurred. Another excellent talk at 25C3 on the iPhone described how the baseband processor was compromised via the lack of validation of RSA signature padding. What’s intriguing is that Apple’s own RSA implementation in their CDSA code was not vulnerable to this flaw, but apparently a different vendor supplied the baseband code.

To paraphrase Gibson, “Crypto security is available already, it just isn’t equally distributed.”

More dangers of amateur crypto

~ Nate Lawson ~ 1 Comment

The Good Math blog continues to inadvertently provide examples of how subtle mistakes in cryptography are often fatal. I previously wrote about how slightly incorrect crypto examples on a reputable blog can lead engineers astray. The latest post about RSA is no exception, but I’ll have to write about it here since my comment was deleted. The comments by Oscar on that post are a good criticism.

The most important error in Mark’s description of RSA is that his example for encryption uses the private key D, instead of the public key E. The result of the RSA private key operation with D is called the “CipherText”. The decryption process is described using the public key E.

At first glance, this seems like an awkward description but still sound, right? If you wanted to exchange RSA-encrypted messages between two systems, couldn’t you just generate an RSA key pair and keep both keys secret? The surprising result is that this is completely insecure, and it is impossible to keep an RSA public key secret, even if the key (E, N) is never revealed.

I previously wrote a series of posts about a system that made this exact mistake. The manufacturer had burned an RSA public key (E, N) into a chip in order to verify a signature on code updates. This is perfectly fine, assuming the implementation was correct. However, they additionally wanted to use the same public key parameters to decrypt the message, keeping E and N secret. In the first article, I described this system and in the second, I discussed how to attack it given that the attacker has seen only two encrypted/signed updates. In summary, the modulus N is partially revealed by each message you see “encrypted” with (D, N) and the GCD quickly computes it.

Subtle details matter, especially in public key crypto. The two keys in an RSA pair are indeed asymmetric, and have very different properties. They cannot be substituted for each other. You cannot securely encrypt a message using the private key (D, N). Such a system would be completely insecure.