On 15/09/2015 08:06, Michael Heide wrote:
Am Mon, 14 Sep 2015 21:01:49 +0200 schrieb Jakob Bohm <[email protected]>:
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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
