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
