You need to have one zero octet after bunch of FFs and before DER encoded has blob in order to have a proper PKCS#1v1.5 signature encoding.
Based on what you say below, "I used this cert and my key to sign an end-entity certificate which I used to set up an webserver", it appears that implementations you used don't check for this one zero octet, either. - Tolga > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Erik Tews > Sent: Thursday, September 14, 2006 3:40 PM > To: Cryptography > Subject: Real World Exploit for Bleichenbachers Attack on SSL > fromCrypto'06 working > > Hi > > I had an idea very similar to the one Peter Gutmann had this > morning. I managed to write a real world exploit which takes as input: > > * an CA-Certificate using 1024 Bit RSA and Exponent 3 (ca-in) > * a Public Key, using an algorithm and size of your choice > (key-in) > > and generats an CA-Certificate signed by ca-in, using public > key key-in. > > At least 3 major webbrowsers on the marked are shipped by > default with CA certificates, which have signed other > intermediate CAs which use > rsa1024 with exponent 3, in their current version. With this > exploit, you can now sign arbitary server certificates for > any website of your choice, which are accepted by all 3 > webbrowsers without any kind of ssl-warning-message. > > I used the following method: > > I first generated a certificate, with BasicConstraints set to > True, Public Key set to one of my keys, and Issuer to the DN > of a CA using > 1024 Bit RSA with Exponent 3. I used usual values for all the > other fields. When I signed a Certificate I shiftet all my > data to the left. I had 46 bytes of fixed valued (this can > perhaps be reduced to 45 bytes, I have not checked yet, but > even with 46, this attack works). They had the form 00 01 FF > FF FF FF FF FF FF FF ASN1DataWithHash. This gives me 82 bytes > I can fill with arbitary values (at least, if the > implementations skipps some part of the asn1-data, I can > choose some bytes there too). > > If you now set all the bytes right of your ASN1DataWithHash > to 00, and interpret that as a number n, and compute: > > y = (ceil(cubeRoot(n)))^3 > > Where ceil means rounding to the next bigger natural > number and cubeRoot > computes the third Root in R. > > y will be a perfect cube and have the form: > > 00 01 FF FF FF FF FF FF FF FF ASN1DataWithHash' Garbage > > and ASN1DataWithHash' looks quite similar to your original > ASN1DataWithHash, with perhaps 2-3 rightmost bytes changed. > These bytes are part of the certificate hash value. > > This signature is useless, because every certificate has a > fixed hash value. But you don't need to sign a fixed > certificate. So i started adding some seconds to the notAfter > value of the certificate and computed the hash again. I brute > forced until I had a certificate where the computation of y > did not alter any bytes of the ASN1DataWithHash. > > I had to try 275992 different values which took 2-3 minutes > on my 1.7 GHz Pentium using an unoptimized java-implementation. > > I used this cert and my key to sign an end-entity certificate > which I used to set up an webserver. > > I have to check some legal aspects before publishing the > names of the browser which accepted this certificate and the > name of the ca-certificates with exponent 3 I used in some > hours, if nobody tells me not to do that. Depending on the > advice I get, I will release the sourcecode of the exploit too. > > Thanks go to Alexander May and Ralf-Philipp Weinmann who helped me. > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
