Re: Should we sign DLLs used by a CSP.
- From: "Jan Spooren" <jspooren@xxxxxxxxxxxxx>
- Date: Mon, 26 Mar 2007 22:35:34 +0200
Hi Jurko,
I'm going to give you my personal opinion and insights, for what they're
worth.
This information is provided as is and is endorsed by no-one.
Yes, the CPAcquireContext function passes the VTableProvStruc, which
contains a function pointer that you can use to verify the signatures of
dlls that you use. This functionality works nicely; even on executables
(not just dlls) and can be used as an extra barrier to make it harder for
malware to intercept calls from your CSP to another component in your
solution. It's harder; because an adversary would need to get his component
signed by Microsoft; which would at least create an audit trail of sent
e-mails and used IP addresses.
I believe the signing of CSPs originated from the time that the US
government had export restrictions on cryptography. It was a legal
requirement for Microsoft to have CSPs signed, in order to make sure when
they shipped a version of Windows with weak cryptography, that people
wouldn't be able to just write a strong crypto CSP and add it to Windows.
The requirement in Windows to load signed CSPs was therefore more of a legal
requirement, rather than a security requirement. You may have noticed that
in the new cryptographic APIs (CNG) smart card CSPs have been replaced with
smart card mini-drivers, which do not need to be signed anymore. (Unless
you 're writing a certified minidriver, in which case there IS a thorough
verification, by a third party certification service).
As you well observed, Microsoft does not claim to do any verification when
signing a CSP. As far as I know, there is no security audit of a CSP before
it gets signed, which makes sense if you consider the signing an (obsolete)
legal requirement.
I've tested CSPs in Windows 2000, Windows XP, Windows Server 2003, Windows
Vista Business and Ultimate, with several service pack versions and none of
those versions enforced the fact that dlls loaded by your CSP must be
signed. I woud be extremely surprised if Microsoft decided to enforce
signature checking of dlls loaded by your CSP. With the CNG; the CSP
technology is being phased out; it wouldn't make sense to make sudden
changes like that.
That having been said, I would strongly encourage you to add a signature
verification scheme to components you are using, if order to guarantee that
you are making calls to components that haven't been tampered with. You
can use the Authenticode APIs to do this, but you may run into trouble with
CRL checking on systems that do not have Internet connectivity. This can
result in systems that seem to hang for 30 seconds. I haven't found a way
around this, without switching off all Authenticode CRL checking.
Implementing your own signature and verification logic to your components
may be the easier option.
In any case, calling functions on unsigned components would i.m.o. not be a
good practise, and I would really advise against that; unless all of the
passed parameters and return values can be considered not to be sensitive
information. That is rarely the case with CSPs.
There you are: My $0.02 ...
Cheers,
Jan.
"Jurko Gospodnetiæ" <mangled@xxxxxxxxxx> wrote in message
news:eNV5s$7bHHA.4888@xxxxxxxxxxxxxxxxxxxxxxx
[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
.
- Follow-Ups:
- Re: Should we sign DLLs used by a CSP.
- From: Jurko Gospodnetić
- Re: Should we sign DLLs used by a CSP.
- References:
- Should we sign DLLs used by a CSP.
- From: Jurko Gospodnetić
- Should we sign DLLs used by a CSP.
- Prev by Date: Re: Followup to TLS Handshake Problem - John Banes I need you
- Next by Date: Re: Followup to TLS Handshake Problem - John Banes I need you
- Previous by thread: Should we sign DLLs used by a CSP.
- Next by thread: Re: Should we sign DLLs used by a CSP.
- Index(es):
Relevant Pages
|
