Introduction

As part of releasing your game to the public, something which is often overlooked is code signing.

Code signing is a cryptographic process whereby your game's executables and/or installer are marked as authentic, so that the person running the executable (or anyone else for that matter) can ensure that:

• The executable has not been changed since it was signed
• The executable was created on a specific date at a specific time
• The executable was signed by a known, trackable entity (company or individual) responsible for the code within

These give some definite advantages (as well as introducing some disadvantages) as shown below:

Advantages of code signing

• Signing your executables provides tracability of your code, allowing anyone to see who is responsible for the program
• Signing adds authenticity which makes your game and your company (if there is one) more reputable and trustworthy
• It will give positive weight to systems such as smartscreen filter and many anti-malware programs, which are more permissive of signed executables than unsigned.

Disadvantages of code signing

• There is an up-front cost involved in aquiring a certificate for code signing
• If you do not have the required forms of identification or business documentation, obtaining a certificate can be hard to impossible
• There is a learning curve to understanding how certificates work (which this article hopes to address)

The steps involved in signing your code

To properly sign your code, you must follow several steps, which must be completed in a strict order. These steps are:

Select a certificate authority

Before you can sign your program code, you first need to select a certificate authority. The cost of object code signing has come down massively in price over the past few years. You will need to search for a certificate authority that will provide you with a type of certificate known as an "object code certificate" or "authenticode certificate".

Here are some possible choices, this list is by no means exhaustive and I encourage you to search for additional sources of certificates before parting with any money:

• StartSSL - You will need to pay for "StartSSL Verified" at $59.90 per year. Certificates last two years after which they must be renewed.
• Comodo - This costs $119.95 per year, however if you are a member of Tucows this can be reduced to $75 per year simply by purchasing through Tucows as a member.
• Verisign/Symantec - Traditionally the most expensive choice but popular with big business. Starts at $795 per year.

Remember to shop around as many different resellers of certificates offer their product at a much lower price through third parties, for example as a business user you can get brand name certificates at a much lower price via RapidSSL.

Also remember that a lot of the time, you are paying for brand names. All certificates I have listed here are equally trusted by the Windows operating system, so there isn't much point in paying $795 per year for a certificate when one you pay $59.90 a year for will function identically.

Purchasing a certificate

When you have selected a company to purchase your certificate through, you will then need to purchase your certificate through their shopping cart (unfortunately, I cannot really advise how to do this as it varies from website to website, but the concept is similar - provide payment details and wait to hear from them).

As part of the purchase you will either have to upload signed forms of your photo identification or business documentation to the certificate authority's website (so be prepared to do this, there is no way around it).

Generally, it is expected for a non-business user to be able to send scanned copies of a photo driving license and/or passport, and a recent utility bill. Also, expect to hear from the certificate authority directly via your phone number, which will be a mandatory field on the application form. This will be a call to verify your identity, and not a sales call. Generally, the level of checking for a code signing certificate is somewhat similar to that needed to open a bank account.

The reason for both of these is to prove you are who you say you are so that the certificate you are purchasing has some weight. This prevents you for example from signing up and buying a certificate claiming to be "Microsoft" or "Google" as to do so you would need that company's business documentation.

Once you have completed the process, you will be sent a link to download a certificate file.

Downloading the certificate file

Once the certificate authority has provided you with a link to download your certificate, you will then have in your possession one or more small encrypted files. You will either have (depending on the authority you selected) a seperate .crt and .key file, or a .pfx (or p7k) file, which is the .crt and .key files combined into one.

You should make sure that these files are backed up securely, as if you lose them you may have to pay for re-issue of your certificate which can be costly. My advice is to move them immediately to a DVD-ROM and lock them away wherever you keep your paper driving license and home insurance, or whatever else holds value to you.

SSL and signing fundamentals

Before we continue further with the article it is worth pointing out the difference between the certificate and key (.crt and .key file) which you have obtained from your certificate authority.

Both are important and have different uses. When you first sign up for your certificate authority of choice a "private key" is generated. This is used to uniquely identify you, and if lost can never be replaced.

Depending on the authority you choose, some may trigger creation of this file by your browser, and have it stored in your registry or browser settings (in which case it is never sent to the certificate authority, which is more secure) and others may generate it for you, and send it to you with your certificate.

Either way, in the end it is used as part of the certificate which is sent to you.

The certificate is a blob of data created by your certificate authority, and then signed by both your key (see above) and the key of your certificate authority, wihch you will never have in your possession. In simple terms, to sign your certificate means to apply a hash to it using the private key of the signer in such a way that you may verify it without that key but may not re-create it yourself, allowing you to verify its authenticity but not forge its content.

There is much more to the process, delving deep into complex maths and cryptography, but that is beyond the scope of this article which intends to simplify code signing rather than make it complex.

Saving the certificate file

If your certificate authority has provided you with a .cer and .key file, I advise that before you continue, you convert it to a .pfx file as it is easier to work with on Windows. There are several ways to convert your files, and your certificate authority might provide you with an online tool or a simple download of your certificate in .pfx form. If they do, I suggest you use this feature as it will be more straightforward.

If they do not provide such a facility, you can use the openssl toolkit to convert your .cer and .key file into .pfx using the command line below, for which you will need to install the openssl toolkit onto your PC, which is a free open source download:

openssl pkcs12 -export -out yourcert.pfx -inkey yourkey.key -in yourcert.cer

The program will prompt you for a password, as part of the process I strongly recommend you enter a strong one as this will protect your certificate from misuse if it is obtained by any third party!

Once you have the .pfx file, simply double click it and windows will prompt you to add it to your registry:



You should mark the certificate as "not exportable" which will stop someone from simply extracting the certificate from your registry at a later date.



Following through the wizard will prompt you for the password you set on the file, simply enter it, and continue clicking through the wizard accepting the defaults.



Once complete, you will receive a message saying the certificate was successfully imported into your registry, which means you are now ready to sign executables!



Please remember that the certificate you have purchased is valid for signing files until its expiry date so you only have to buy the certificate once every one or two years (or however long the certificate is valid for) and with this one purchase you can sign as many executables as you like, whenever you like. After this, the sky is literally the limit!

Signing your executables, and timestamping

We now finally have the correct configuration and the correct files to be able to sign our executables. It is important to note however that there is one important difference between signing an executable, and putting an SSL certificate onto a website or most other uses of security certificates. Binary code may be timestamped.

What this means, in simple terms, is that the signed executable can still be considered valid even if your certificate has expired, you just wouldn't be able to sign any new files with an expired certificate. To prove my point find any signed executable on your disk which is over three years old. The chances are, by now the certificate which was used to sign this file has expired (you can see this by right clicking on the file and choosing properties, then the 'security' tab) however if the file is timestamped, when you double click the file it will still be considered valid.

Timestamping is a process done automatically when you sign your file. It involves contacting a third party server which counter-signs your file with a special value which references back to the certificate issuer's servers. This value can then be used to verify that the certificate was valid at the time of signing the file rather than right now. Because of this, you should always use your certificate authorities own timestamp server which you can easily find on Google.

Armed with this information, signing your code is quite straightforward:

"C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe" sign /d "Your games name" /tr http://www.startssl.com/timestamp /a path\to\your\executable.exe

In the command above we are using the signtool.exe binary, which comes with the Windows 8 development kit. There will likely be several copies of this executable on your disk and any one of them will do fine for this task.

We specify the "friendly name" of our program using the /d parameter, as shown above, and the /tr parameter specifies the timestamp server as we discussed above.

The command above can be used not only to sign executables, but also DLL files and OCX files, driver files, CLR bytecode, and just about any other type of windows executable you can imagine.

Specifying the /a parameter to the signtool command simply tells it to use the first valid code signing certificate held within your registry to sign the file. If you followed this article to the letter this is where your code signing certificate and key will currently reside.

I store my code signing certificate here as it is generally a secure place to put it, where you don't risk accidentally putting it into your code repository or into your network drives, encrypted or decrypted.

Now you have finished the process, you can test your executable by double clicking it, and if your executable requires elevation (which most install packages etc do) then you will be presented with the friendly blue prompt:

Summary

Hopefully this article should give you some insight into how to sign your code. Signing your code is not just an akward expense, in the current software and games market you should consider it important for anything you release to the public. It protects you, and it protects the people who want to play your game.

If you have any questions about this article please do not hesitate to comment on this article below.

Article Update Log

21 Apr 2015: Started work on article
7 May 2015: Initial release