• What to sign? According to the MS various logo programs: “All executable files must be signed with an Authenticode certificate. This includes files with the following extensions: exe, dll, ocx, sys, cpl, drv, scr”. However, this  puts some penalty on the startup time of applications. This is because the machine needs to check that the certificate is still valid and has not been revoked. This delay maybe significant if the computer cannot access the net to do the validation. Some information on the problem (albeit old) can be found here. Nevertheless the problem seems to still hold for pre-NET 2.0 assemblies

• Another thing that one needs to be careful of, is the fact that software may exist forever, whereas certificates don’t. Generally certificates expire after some time. In order to avoid a situation where perfectly signed software stops working because its certificate expired, it is a good idea to timestamp all signed software. You can do this via the /t parameter. Thus, a command such as the following:

signtool.exe sign /f BogusSite.pfx /p <bogusSitePassword>/t “http://timestamp.verisign.com/scripts/timstamp.dll” SigningDemo.exe

will timestamp the signature (this is what the /t parameter does). The “http://timestamp.verisign.com/scripts/timstamp.dll” argument takes the timestamp from a free service provided by Verisign (this way we ensure that the timestamp is valid).

Putting the timestamp helps, because all it matters now is whether the certificate is valid at the time the file is signed (the time in the timestamp), and not at the time the program executes.

1. Get a certificate from a trusted certification authority
2. Sign your .exe files with the digital signatures found in this certificate.

However, since most people who want to try out this technology do not actually own a trusted certificate yet, a “dummy” certificate first needs to be created. This post will try to explain the whole process.

Step 1: Create a “trusted” certification authority

MS Windows ships with a bunch of certificates that are generally considered to be trusted. These are certificates from companies such as Verisign, Thawte etc. These certificates are stored in the certificate store of your machine. You can have a look at it by running the command certmgr.msc. You can see there that there is a Trusted Root Certification Authorities store, where all the certificates of such entities are stored. If you go and buy a certificate you basically get something that says that one of the trusted root certification authorities trust that you are who you say you are and by extension (since Windows trusts these authorities) Windows also trust that you are who you say  you are.

So the first step towards the road of creating numerous bogus certificates is to create one bogus certification authority and tell your machine that you trust it to be reliable. To do this we have to use one useful command line tool, namely makecert.

So,

you can issue the following line:

makecert -r -pe -n “CN=BogusCert.com” -cy authority -sv “BogusCertPrivateKey.pvk” BogusCert.cer

which basically says:

-r: create a self-signed certificate

-pe: in such a way that its private key is stored together with the certificate (i.e. it is exportable)

-n: for the company with the (canonical name) BogusCert.com

-cy: the certificate represents a (certification) Authority

-sv: create and store the private key into file BogusCertPrivateKey.pvk

BogusCert.cer is the file where the certificate will be stored

After you run this command you will be asked to insert a private key of your choosing with which contents will be signed. You will have to enter the same key three times.

And in the end the certificate will be created and stored in file BogusCert.cer

After that you will have to import this certificate in your certificate store, i.e. you will have to run certmgr.msc go to the Trusted Root Certification Authorities, right-click and select “All tasks” and then select “Import…” and import BogusCert.cer as a trusted certificate.

This way you have explicitly told Windows that you trust BogusCert

Step 2: Create a trusted certificate

In the next step we can create our own certificate, and use the BogusCert authority to certify that is valid…

makecert -n “CN=bogusSite.com” -ic BogusCert.cer -iv BogusCertPrivateKey.pvk -pe -sv bogusSiteKey.pvk bogusSite.cer

This time we say that we need a certificate

-n: for the company with the (canonical name) BogusSite.com

-ic: that is issued by BogusCert (thus, we specify the certificate of BogusCert.cer)

-iv: and is signed with the private key found at BogusCertPrivateKey.pvk

-pe: in such a way that its private key is stored together with the certificate (i.e. it is exportable)

-sv: create and store the private key of our new site into file bogusSiteKey.pvk

and bogusSite.cer is the newly created certificate

You will be asked three times for the private key of the new certificate, and one time for the private key of the certification authority (i.e. BogusCert, the private key you typed in the previous step). Thus we have created a new certificate which is “issued” by BogusCert

Step 3: Transforming certificates into the correct formats

For some reason that I don’t know, certificate files, private keys etc come in various different formats. Out of the many formats the ones that interest us are the following

.cer format, which is the Microsoft version of a certificate file. Basically it stores the certificate in the X509 format (but it usually does not store the private key)

.pvk format which is a Microsoft format for storing private keys

.spc format which is the “Software Publisher Certificate”, another certificate format which is equibalent to the .cer format

.pfx personal information exchange format. The difference between this and the .cer format is that the pfx format stores the private key together with the certificate.

For more information one can have a look at the PKCS#n suite of standards regarding certificates.

Now in order to sign a file it is useful to have a certificate with the private key into one file, so we need to take the .cer certificate and the .pvk private key file and change the certificate into the .pfx format.

This can easily be done with the following command

pvk2pfx -pvk bogusSiteKey.pvk -pi <privateKeyPass> -spc bogusSite.cer

where <privateKeyPass> is the password you put for the private key of bogusSite

When you run the command you will be asked whether to include the private key in the new certificate. Select Yes

Then select the pfx file format and then type in a new private key for the pfx file.

Select where the pfx file (e.g BogusSite.pfx) will be stored and you are done!

Step 4: Sign the file

The last step is to run the signtool utility and actually sign the file.

Try:

signtool.exe sign /f BogusSite.pfx /p <bogusSitePassword>/t “http://timestamp.verisign.com/scripts/timstamp.dll” SigningDemo.exe

in order to sign the executable called SigningDemo.exe (or whatever else executable you want to sign)

Now if you right-click on SigningDemo.exe you will see a tab saying “Digital Signatures” and the digital signature of BogusSite!

(For an explanation of the /t parameter see my next post)

• Strong singing, i.e. digitally sign a dll to ensure its uniqueness and integrity
• Autenticode, i.e. signing code to ensure that the code’s publisher is who he say he is

To do the first take a look at:

• http://msdn.microsoft.com/en-us/library/xc31ft41.aspx
• http://msdn.microsoft.com/en-us/library/t07a3dye.aspx
• http://msdn.microsoft.com/en-us/library/6f05ezxy.aspx

To do the second take a look at:

• http://msdn.microsoft.com/en-us/library/8s9b9yaz(v=VS.100).aspx
• http://www.tech-pro.net/code-signing-for-developers.html

More info tommorow when I will actually follow the steps described above!