Should we sign DLLs used by a CSP.



[This is a repost of a question already posted to the microsoft.private.directaccess.security newsgroup where Microsoft's support redirected us to MSDN managed newsgroups of which this one seemed the most appropriate.]

Hi.

Our CSPs get signed by Microsoft for each new release and so work on all the supported Windows machines without the need for any changes to the system's advapi32.dll DLL.

However, we have gotten some contradictory information regarding whether we need to sign all the DLLs our CSPs may load at run-time as well.

CSP documentation found on the MSDN seems to imply that if you want a CSP to load another DLL at run-time it should do this using the LoadLibrary() API and only after verifying the DLL's signature using the API provided via one of the CPAcquireContext() parameters. [See the CPAcquireContext() API documentation at http://msdn2.microsoft.com/en-us/library/aa378175.aspx, and the VTableProvStruc documentation at http://msdn2.microsoft.com/en-us/library/aa388195.aspx.]

On the other hand, our CSPs load the OpenSSL DLL at startup and seem to run happily on all the systems we tested.

We inquired about this on the cspsign@xxxxxxxxxxxxx e-mail address used for submitting CSPs for signing and got the answer that the current functionality is 'by design' and will not be changed, however... we would like to be sure of that. Could you please tell us whether this is in fact so or if we should sign any OpenSSL DLLs in order not to risk having some future Windows Update break our software? Also... if this is so, then could you please arrange for the CryptoAPI MSDN documentation to be updated accordingly?

And if the current behavior is in fact 'by design' then is seems it would be ok for someone to simply get a dummy interface CSP signed and have it load the actual CSP at run-time - thus removing the need for future CSP signing all together and speeding up the CSP release procedure. Was this the intent when choosing this design?

Thank you in advance.

Best regards,
Jurko Gospodnetić


--
Docte d.o.o.
Maksimirska 48/I
10000 Zagreb
Croatia
Tel: +385 (1) 2396-684
.



Relevant Pages

  • Re: Identity Impersonate - help!
    ... getting CSP problems. ... or perhaps your ASPNET user doesn't have the ... Have tried to find out why I get this message, searching MSDN ... > not recommend giving this privelege to the ASPNET user. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Kerberos TGT Anforderung
    ... Im MSDN und entsprechenden SDK's wird der Returncode ... in denen des LSA und KDC beschrieben wird. ... > Es könnte ein Problem des cryptographic service providers (CSP) sein. ... Next by Date: ...
    (microsoft.public.de.security.netzwerk.sicherheit)
  • Re: SChannel CSP : Not up-to-date info in MSDN
    ... I would suggest writting a simple logging CSP to get started. ... When testing an schannel CSP, these are much better to use than IE ... Please do not send email directly to this alias. ... > I did search MSDN, and managed to find various pieces of information at ...
    (microsoft.public.security)
  • CPDecrypt question
    ... I have question connected to CPDecrypt CSP function. ... "If a block cipher is used and dwFlags is TRUE, any padding data must be ... CSPs and other smart card CSPs removes padding for block ciphers. ... API described in MSDN, but implement only behaviour of MS base CSP. ...
    (microsoft.public.platformsdk.security)
  • SChannel CSP : Not up-to-date info in MSDN
    ... I am writing a CSP that can support both SChannel and non-SChannel ... The CSP entry points in MSDN do not explain much about the flags and ...
    (microsoft.public.security)