Re: Programmatically Signing DLL
From: Michel Gallant (MVP) (neutron@istar.ca)
Date: 01/15/03
- Next message: x y: "Re: profile"
- Previous message: x y: "Re: win 98 logon password"
- In reply to: Richard Parker: "Re: Programmatically Signing DLL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 15 Jan 2003 12:25:46 -0500 From: "Michel Gallant (MVP)" <neutron@istar.ca>
--see embedded comments--
Richard Parker wrote:
> "Michel Gallant (MVP)" <neutron@istar.ca> wrote in message news:<3E244972.D63E19CD@istar.ca>...
>
> > I assume you *don't* want to invoke a separate process via ShellExecute(..) or system(...) with
> > signcode -spc etc.... ??
>
> Well no I don't, I want someone who may not be that technical to be
> able to take a floppy or CD from a safe somewhere with certificate and
> key on it and sign a .DLL before it goes into production. The
> application that does the signing would upload the DLL to the server
> after it had been signed. I don't want anyone to have to install the
> INETSDK or be able to replace signcode deliberately, or accidentally
> (why is signcode.exe NOT SIGNED???).
Good question. Most exe like that that you find, were distributed via an
installer that WAS signed, vouching for all the contents within it. Since
Authenicode signing adds ~ 1 kbyte of data, it wouldn't be a big deal to
sign every .exe, but this does not seem to be the current MS practice.
> > I think that spc and pvk (proprietary format) are ONLY supported by the signcode.exe
> > tool.
>
> Well someone must have had a subroutine at least to write signcode.exe
> in the first place. Don't Microsoft use their own SDKs?
There are a lot of examples like this that use MS internal dlls/apis (i.e. api is not public).
>
> > If you insist on using local files (instead of direct access of keys/cert in system stores)
> > for the keys/cert, then probably a better approach is to use a .pfx (pkcs12) file, which
> > holds both keys and cert. CAPICOM, again, has excellent support for this;
> > e.g. some relevant VBScript code:
> > Dim Signer, SignedCode
> > Set SignedCode = CreateObject("CAPICOM.SignedCode")
> > Set Signer = CreateObject("CAPICOM.Signer")
> > ....
> > Signer.Load PFXFileName, PFXPassword
> > SignedCode.FileName = filetosign
> > ' set other SignedCode properties ....
> > SignedCode.Sign Signer
>
> Yes, I've seen that code. What I need is to know:
>
> What kind of certificate do we need to buy to allow programmatic
> signing and validation of a DLL using VC++. There can be no additional
> components needed for validation (this is going to be deployed on over
> 100,000 desktop PCs) and ideally no additional components needed for
> signing. The OS is W2K and XP.
To Authenticode sign (either manually or programatically) you need a class 3
code-signing certificate (Thawte, Verisign etc..).
If you require ABSOLUTELY NO EXTRA COMPONENTS, then you are
talking about some fairly low level, and probably error-prone coding in
C, and trying to understand how the pkcs7 block is inserted into the Authencode-signed
file (different approach for .exe, .dll, .vbs etc..). Note that all Win32 OS, with
IE5+ can properly verify the validity of an Authenticode signature (build into
the security infrastructure via various system component installs). You right
click the file and look for the Digital Signatures pane. Also, if you directly download
an .exe form a web site, and choose to Run it, you will be presented with an Authenticode
verification dialog.
As I mentioned before, the CAPICOM install is a no-brainer, fast install, no reboot
required (capicom.cab is a mere ~ 175 kbytes). Once your clients have this, then
your development effort for automation of digital signing/encryption/verification etc..
will be much much easier ... and you could choose development language of your choice:
VB, C, Java, Script etc.c.
Here is an example of such functionality which allows end users (on any of Win95 -XP) to
very easily envelope (encrypt to any recipients) any file on their system:
http://pages.istar.ca/~neutron/cryptoutils/jacrypt
The link at page bottom directs potential users to the required (simple) CAPICOM 2 install.
The same approach could be used for signing any file, using identical certificate access.
Of course, most of the functionality could be hidden, if you know for sure where there users
certificates (in your case, class 3 code-signing certs) are located.
>
> We are about to embark on the process of buying certificates from
> Thawte - I don't want to advise my client incorrectly.
You will need a Class 3 code-signing certificate for this.
>
>
> Regards,
>
> Richard Parker
- Next message: x y: "Re: profile"
- Previous message: x y: "Re: win 98 logon password"
- In reply to: Richard Parker: "Re: Programmatically Signing DLL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
