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

[Jakob Bohm]

On 11/09/2015 23:26, Michael Heide wrote:
> Am Fri, 11 Sep 2015 15:07:20 +0200 schrieb Jakob Bohm <jb-openssl at wisemo.com>:
>
>> 2.3.1 RFC2985 form Timestamp countersignature Attribute
> This one.
I thought so, many people think this one is proprietary,
not realizing it was in the original PKCS#9 document.
>> I have not encountered this before, which signing authority,
>> AlgorithmIdentifier and year (first digits of timestamp) did
>> you see this with?
> Various intermediate certs. Verisign, Symantec, etc.
> But now I see, did't got it before: the root is always "Thawte Timestamping CA" -- using md5WithRSAEncryption.
In other words, the Verisign/Symantec conglomerate,
which for many years used that timestamping facility
across all its brands, including German brands
"geotrust"and "tc trustcenter".

However, I don't think they stopped using MD5 for all
but the old top level CA a long time ago by now.
>
> Example:
> https://www.virustotal.com/en/file/1d1bb76575e780123814259eb2dbbf26f1c9035d8f0d4bab682703823b06323f/analysis/
I'll have to have a look at that.
>
>> Have you considered the possibility that this may be an
>> ISO/IEC 9796-1 or -2 signature (an old format broken in
>> 1999 for 9796-1 and for 9796-2/MD5 and in 2009 for
>> 9796-2/SHA-1)?
> ISO/IEC 9796-1 / -2 seems to be completely different signing schemes. That's not the case here. It's only the encryptedDigest which differs, everything else is quite like the other timestamps you describe in "2.3.1".
ISO/IEC 9796-1/-1 specifies a different way of doing
the encryptedDigest calculation, not a different
surrounding OSI/ITU structure around it.
>
> Btw: Windows verifies those with success, valid signatures. But you are right, maybe those are "fakes" (the intermediate ones) or broken in another way.
Not so fast.  From what you describe, these use an
old/wrong way of doing the EncryptedDigest calculation,
and it is highly likely that Microsoft have had to make
a (hopefully limited) exception for those historic timestamps.


>> Due to the likely weakness of this scheme, [...]
> I'm a layman here, but I don't think the differences in the scheme itself provides the weakness, not in this case. There's only one difference: The signature algorithm is not confirmed by the encryptedDigest. But it is via other places and it is sha1 for the timestamp itself (20 bytes in length).
I'm no expert either, but from what I read, the weakness
was precisely in the way the 128/160 bit hash was turned
into a 1024+ bit number to be "encrypted" with the RSA
private key.

The PKCS#1 v2.x format (still not supported by Microsoft)
was designed to provide the best possible way of doing
this safely, while the older PKCS#1 v1.x format was less
carefully designed, though it still seems to be holding up.

The ISO/IEC 9796-1 and -2 formats were badly designed, and
simply using a zero-padded hash value would be even worse.

The dangers in all cases are about what happens if someone
bad carefully constructs signing request (which wouldn't
match any actual outer signature and would thus not be in
a valid signature timestamp signature), they could use the
answers to calculate the keys of the timestamping authority,
a bit similar (though not exactly) to how someone calculated
the private key used by Sony to sign approved PS3 software
disks.

This is why I am asking which specific authorities and
periods made the mistake of calculating the input to the
"encryption" wrong, and when they stopped doing so.


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