[openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Jakob Bohm]

On 15/09/2015 08:06, Michael Heide wrote:
> Am Mon, 14 Sep 2015 21:01:49 +0200 schrieb Jakob Bohm <jb-openssl at wisemo.com>:
>
>>> Seems to be a file with the same criteria here.
>> That one is a big surprise to me.
> Thanks.
>
> (if it's a surprise to you, then it's ok to be a surprise for me too. ;-) )
>
>> 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.
> 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.
Yes, it was just rare enough to make me suspicious.
>> 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.
> 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.)
Of cause, my problem was what bytes to pass to the digestion
process, I couldn't find the right subset, even after
double checking the PKCS#7 spec and trying different
interpretations of the standard text.
>> 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.
> ok, sounds good. Maybe that's the reason for *1 (see below):
> It seems they think there are no known security drawbacks!?
Where is *1 ?
>
> 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()]
Of cause, this error is really at the PKCS#1 level, even
though the PKCS#7 standard formally repeats that particular
part of PKCS#7 due to ISO/OSI/ITU fun with BIT STRING vs.
OCTET STRING notation.
>>> No, I'm not. Maybe I'm doing something wrong. I don't know.
>> It seems not, now I really wonder what is going on.
> me2
>
> Maybe simply nobody thinks about it because it's accepted even by the
> brand-new Windows 10. Maybe because of *1 (see above).
Yep, it is probably also accepted by Microsoft's generic PKCS#7
code, since I have in the past checked timestamps from that
server in that way and not noticed the deviation.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150915/6cf27e03/attachment-0001.html>