<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 15/09/2015 08:06, Michael Heide
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_20150915080644_53ffa92b_tbb_phenom"
cite="mid:20150915080644.53ffa92b@tbb-phenom" type="cite">
<pre wrap="">Am Mon, 14 Sep 2015 21:01:49 +0200 schrieb Jakob Bohm <a class="moz-txt-link-rfc2396E" href="mailto:jb-openssl@wisemo.com"><jb-openssl@wisemo.com></a>:
</pre>
<blockquote class=" cite" id="Cite_9888064" type="cite">
<blockquote class=" cite" id="Cite_9603812" type="cite">
<pre wrap="">Seems to be a file with the same criteria here.
</pre>
</blockquote>
<pre wrap="">That one is a big surprise to me.
</pre>
</blockquote>
<pre wrap="">Thanks.
(if it's a surprise to you, then it's ok to be a surprise for me too. ;-) )
</pre>
<blockquote class=" cite" id="Cite_1105571" type="cite">
<pre wrap="">It seems that as late as in August 17 2015 (4 weeks ago),
Symantec/Verisign issued a timestamp signature, whose
"EncryptedDigest"was made on the following non-standard
input:
00|01|FF...|00|00 87 34 69 20 D5 4C 68 F4 B1 30 6DEA 3E 40 CC B7 71 AC 1D
The first parts (00|01|FF...|00) form the PKCS#1 padding
for a PCS#1 v1.x signature.
But the last part is a 20 byte string that doesn't seem to
match anything permitted by PKCS#1 v1.5 (or v2.1). I also
note that the SignerInfo specifies "version 1" (aka PKCS#7
v1.5), so I don't think this could be the elusive PKCS#7
v1.4 signature format.
It might hypothetically be an SHA1 SUM, but the initial 00
byte looks strange.
</pre>
</blockquote>
<pre wrap="">That's life. sha1 sums can start by any value between 00 and FF.
By change the sha1 sum can even be all 00. Would simply be a remarkable
coincidence. I have several other files of this type here and
this is the only one starting with 00.
That means: the corresponding hash value calculated in
EVP_VerifyFinal() also starts with 00.
</pre>
</blockquote>
<tt>Yes, it was just rare enough to make me suspicious.</tt><br>
<blockquote class=" cite"
id="mid_20150915080644_53ffa92b_tbb_phenom"
cite="mid:20150915080644.53ffa92b@tbb-phenom" type="cite">
<pre wrap="">
</pre>
<blockquote class=" cite" id="Cite_9198016" type="cite">
<pre wrap="">I am struggling a bit with trying to figure out what bytes
are covered by the hash value, so far I have failed to
manually extract a relevant subset of of the message, but I
may have made some basic mistake since I usually don't do
this by hand.
</pre>
</blockquote>
<pre wrap="">Me neither. I use gdb and/or add debug output to OpenSSL.
the full hash:
00 87 34 69 20 D5 4C 68 F4 B1 30 6D EA 3E 40 CC B7 71 AC 1D
calculated via EVP_DigestFinal_ex() by EVP_VerifyFinal()
called from PKCS7_signatureVerify() where the authenticated
attributes and their "content digest" is taken into account.
(=> This is a calculated value and not extracted from EncryptedDigest.)
</pre>
</blockquote>
<tt>Of cause, my problem was what bytes to pass to the digestion <br>
process, I couldn't find the right subset, even after <br>
double checking the PKCS#7 spec and trying different <br>
interpretations of the standard text.</tt><tt><br>
</tt>
<blockquote class=" cite"
id="mid_20150915080644_53ffa92b_tbb_phenom"
cite="mid:20150915080644.53ffa92b@tbb-phenom" type="cite">
<pre wrap="">
</pre>
<blockquote class=" cite" id="Cite_582118" type="cite">
<pre wrap="">Well, the good news is that at least the PKCS#1 padding is
still there, which makes it a lot less vulnerable than what
your e-mails made me think.
</pre>
</blockquote>
<pre wrap="">ok, sounds good. Maybe that's the reason for *1 (see below):
It seems they think there are no known security drawbacks!?</pre>
</blockquote>
<tt>Where is *1 ?</tt><br>
<blockquote class=" cite"
id="mid_20150915080644_53ffa92b_tbb_phenom"
cite="mid:20150915080644.53ffa92b@tbb-phenom" type="cite">
<pre wrap="">
Like I said: OpenSSL can handle it like every other PKCS#7
until it tries to decode the decrypted "EncryptedDigest"
via d2i_X509_SIG(), which fails on those non-ASN.1 plain
hash string.
[in int_rsa_verify() in crypto/rsa/rsa_sign.c using
PKCS7_verify()]
</pre>
</blockquote>
<tt>Of cause, this error is really at the PKCS#1 level, even <br>
though the PKCS#7 standard formally repeats that particular <br>
part of PKCS#7 due to ISO/OSI/ITU fun with BIT STRING vs. <br>
OCTET STRING notation.</tt><tt><br>
</tt>
<blockquote class=" cite"
id="mid_20150915080644_53ffa92b_tbb_phenom"
cite="mid:20150915080644.53ffa92b@tbb-phenom" type="cite">
<pre wrap="">
</pre>
<blockquote class=" cite" id="Cite_7094569" type="cite">
<blockquote class=" cite" id="Cite_7516556" type="cite">
<pre wrap="">No, I'm not. Maybe I'm doing something wrong. I don't know.
</pre>
</blockquote>
<pre wrap="">It seems not, now I really wonder what is going on.
</pre>
</blockquote>
<pre wrap="">me2
Maybe simply nobody thinks about it because it's accepted even by the
brand-new Windows 10. Maybe because of *1 (see above).</pre>
</blockquote>
<tt>Yep, it is probably also accepted by Microsoft's generic PKCS#7
<br>
code, since I have in the past checked timestamps from that <br>
server in that way and not noticed the deviation.<br>
</tt><br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>