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.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Erik Tews
Sent: Thursday, September 14, 2006 3:40 PM
Subject: Real World Exploit for Bleichenbachers Attack on SSL
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
and generats an CA-Certificate signed by ca-in, using public
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]