EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Digital signatures: CAPICOM, .NET and SBB

Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.
#12291
Posted: 02/04/2010 03:27:18
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Hello,

I'm looking for some reference about interoperability of digital signatures created with these three toolboxes: CAPICOM, .NET System.Security.Cryptography and SecureBlackBox (7) on VCL.

So that you can understand the problem: I've written a system that makes uses of digitally signed files. The product has been a success but I'm now running into problem when 3rd party vendors tries to interract with it.

Historically, the files where signed using CAPICOM's SignedData object. The reason for this is that it's a simple COM class that is easy to use from scripted environment as well as from .NET, Java or compiled code. SBB is NOT used to validate these signatures but it's used later on to work on the certificate and a lot of other things (cert management, SSL, SFTP).

Now, I have a vendor who refuses to use CAPICOM and wants to use .NET. They even got as far as "suggesting" I switched all the program to .NET just to be able to "support" their signature.

So, basically, I need to know if there is a way to use digital signature produced by these toolkits from another one. Ideally, I'd like to change the validation logic on my side to use SBB exclusively and, for that, I need to support the CAPICOM-generated signatures directly from SBB code (I never managed that). I would also need to seamlessly read .NET generated signatures and validate then in CAPICOM or SBB.

Is there such a resource available ?
#12292
Posted: 02/04/2010 03:56:42
by Eugene Mayevski (EldoS Corp.)

Let that vendor use whatever they like as long as it's PKCS#7 complaint. If their production (the data they generate) is not compliant, then it's bad for them, not for you. SecureBlackbox will handle PKCS#7 data correctly, so most likely it's their badly written implementation which is not usable with anything else other than their own code. I guess that were some indians, who wrote the code, no?


Sincerely yours
Eugene Mayevski
#12293
Posted: 02/04/2010 04:20:28
by Santiago CastaƱo (Standard support level)
Joined: 04/16/2006
Posts: 155

Hi Stephane,

From my experience there's no trouble with a 3rd party signing with CAPICOM, with Java or with .NET directly; we've made lots of interoperability tests with other companies using the previous languages and different libraries for their languages and the result where really good.

- CAdES/CMS/PKCS#7: no problem while verifying other signatures, the others also can fully verify our signatures, but some of them (they're improving their code) read some authenticated attributes from our signatures that they don't know about, and instead of ignoring those attributes they returned error verifying, but as i said they've admited it's incorrect to return error only because that attribute is not used by them. The only thing missing i think is the support of ESSSigningCertificateV2

- XAdES/XMLDSig: There were some things missing and problems with XMLDSig and multiple signatures, but in lastest SBB versions we can verify all the files and they can verify our files also.

- PAdES (PDF long term Advanced Signatures): we didn't do any interoperability tests here, only using Adobe Reader, the only thing we found is that making a PAdES-XL, the revocation information is not correctly parsed by Adobe unless we set NONCE=empty while doing the OCSP request.

There goes my 2 cents on interoperability results...
#12294
Posted: 02/04/2010 04:32:27
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Thank you both for your answer. The vendor that is giving me trouble now claims that CAPICOM doesn't generate "standard" signature and that .NET does (that's basically the escence of the message I got). Like I said, I used CAPICOM historically for signing but also validating (it's always easier to use the same package for both operations). But I'm eager to switch to SBB for that part of the software as well as I'd get a far better control out of it.

Questions: Do I read you correctly: Signing with CAPICOM's SignedData will produce a valid PCKS#7 signature (I'm using a detached signature here) ? I know CAPICOM will pad the data to an even size before signing it so gather I need to do the same for verifying.

And I have no idea where the programmers for this other version comes from, really, but India is, indeed a prime candidate.

Thanks again
#12295
Posted: 02/04/2010 04:48:24
by Ken Ivanov (EldoS Corp.)

Quote
Do I read you correctly: Signing with CAPICOM's SignedData will produce a valid PCKS#7 signature (I'm using a detached signature here) ?

Answering this question requires a bit of clarification. PKCS#7 only declares a format for secured data; there is a number of other standards that utilize PKCS#7 (e.g., CMS, S/MIME, CAdES), but extend it with their own requirements. For instance, CMS requires SignedData to include the "message digest" authenticated attribute. CAdES is even more complicated. This way, a particular SignedData may form a valid PKCS#7 signature, being at the same time invalid from CMS viewpoint.

From our experience I can say that there are very little implementations that produce/process "raw" PKCS#7 signatures. Most of the implementations deal with CMS (RFC 2630 and further). CAPICOM does produce valid PKCS#7 signatures, but unfortunately, I cannot say for sure if his signatures are conformant to higher-level (e.g. CMS) specifications.

Would it be possible for you to attach some messages that are understood and not understood by the recipient's software? We could try to help you by comparing them and finding the differences.

Quote
I know CAPICOM will pad the data to an even size before signing it so gather I need to do the same for verifying.

Hmm, never heard about this. Can you please refer us to some guide (or other document) on this question?
#12296
Posted: 02/04/2010 05:09:17
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Thanks again. It looks like I should do some more reading about PKCS#7...

Quote
Would it be possible for you to attach some messages that are understood and not understood by the recipient's software? We could try to help you by comparing them and finding the differences.


I have attached a sample of what is working today with my application. Production data files are usually XML but sometimes SWIFT messages or even some binary data. In my case, I created a simple ASCII file.

I can't produce any code that isn't validated just yet: the vendor didn't provide any sample except some code that uses their own private classes for signing (talk about "standards") but I'll write a simple .NET sample this afternoon and generate a similar example.

The signature validation code is rather simple:
Code
(ASignedData as ISignedData).Verify(FSignature, true, CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE);


Later on, the code will check a number of things regarding the certificate itself but that's the only way the digital signature is currently validated. ISignedData is a CAPICOM interface.


[ Download ]
#12297
Posted: 02/04/2010 05:10:16
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Quote
Hmm, never heard about this. Can you please refer us to some guide (or other document) on this question?


Sorry, I forgot:

[URL=http://www.codeproject.com/KB/security/CapicomUTF8.aspx]This article[/URL] explains the issue.
#12298
Posted: 02/04/2010 06:24:36
by Ken Ivanov (EldoS Corp.)

Thank you.

Now I see. CAPICOM only signs Unicode UTF16 strings, that's why there is no way to pass an arbitrary byte sequence for signing...

In any case, the signature you have attached is correct. BUT only if the source message (data.txt) is converted to UTF16 little-endian Unicode prior to validating (i.e. I had to open data.txt with Notepad, save it in Unicode encoding and remove two leading BOM bytes). Can it be that your partner cannot validate your signatures for the same reason?
#12300
Posted: 02/04/2010 08:46:32
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Thanks again for answering.

Quote
Can it be that your partner cannot validate your signatures for the same reason?


It's the other way around: they are supposed to provide the file and the signature and I'm supposed to validate it. We decided to use CAPICOM for signature specifically because it's easy to use by 3rd parties: just a couple of properties to set, two calls and then dump the resulting signature block and you're set.

What THEY are saying is that they don't want to use CAPICOM "because it's not standard" and use .NET crypto classes "because it's standard" (never mind the fact that it's only standard among their own developers) so I have to change my validation code to use whatever will come out of their software. never mind the fact that 3 other vendors are already using the CAPICOM component, plus my own client and several scripts as well.

Now, if I follow what you're saying, the data is actually converted to Unicode before being signed. That's really weird.

German to this problem, I've tried to write a very simple verifier for this data file using SBB and I'm always getting an "unexpected end of stream" error in TElASN1Parser.DecodeField and then get error 0x2006. I've tried using the "messages demo" and got the same result. is there anything special I need to do ? I'm just calling ElMessageVerifier1.VerifyDetached with the data and signature streams.
#12308
Posted: 02/04/2010 12:51:46
by Ken Ivanov (EldoS Corp.)

The PKCS#7 message (data.p7b) needs to be unenveloped from base64 prior to passing it to TElMessageVerifier. This can be done with Base64Decode() method from SBUtils.

I am attaching the preprocessed versions of your files. They pass validation successfully for me.

BTW, messages demo does not support validation of detached signatures, does it?


[ Download ]
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 3521 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!