Authenticode Signing for Game Developers
.jpg){kind=small} |
.jpg){kind=small} |
Authenticode Signing for Game Developers
Microsoft Corporation December 2005
Introduction
Security is becoming increasingly important for game developers. Microsoft Authenticode enables end users and the operating system to verify that the code comes from the rightful owner and that it hasn't been maliciously altered or accidentally corrupted. Windows Vista has a number of features such as parental controls that require Windows games to be properly signed to ensure the data has not been tampered. This article discusses how to get started with a test certificate, where to get a public certificate, and how to integrate this into a daily build process.
Background
Digital certificates are used to establish the identity of the author. These digital certificates are issued by a trusted third party known as a Certificate Authority (CA) such as VeriSign or Thawte. The CA is responsible for verifying that owner is not claiming a false identify. After applying to a CA for a certificate, commercial developers can expect a response to their application in less than two weeks.
After the CA has decided that you meet its policy criteria, it generates a Code Signing certificate (CER) that conforms to the industry standard X.509 certificate format with Version 3 extensions. This certificate identifies you and contains your public key. It is stored by the CA for reference and a copy is given to you electronically. At the same time, you also create a private key which you must keep safe and must not share with anyone, even the CA.
After you have a public and private key, you can then begin distributing signed software. Microsoft provides tools to do this in the Platform SDK. The tools utilize a one-way hash, produce a fixed-length digest, and generate an encrypted signature with a private key. It then combines that encrypted signature with your certificate and credentials into a structure known as a signature block and embeds that signature block into the file format of the executable. It should be noted that any executable binary can be signed including DLL, EXE, and CAB files.
The signature can be verified in multiple ways. The WinVerifyTrust function, or signtool.exe can be used to verify a signature from the command line prompt. Windows Explorer also has a Digital Signatures tab in File Properties that will display each certificate of a signed binary. An application can be self-verify by using the WinVerifyTrust API.
Authenticode signing is not only useful for data authentication by end users, but is also needed for Limited User Account Patching and Windows Vista's parental controls. Future technologies in Windows may also require signed code, so it is strongly advised that all professional and amateur game developers acquire a CER from a CA. More information follows on how this is done.
Getting Started
To get started, Microsoft provides tools with Visual Studio 2005 and in the Platform SDK to help perform and verify the code signing process. After installing Visual Studio 2005 or the Platform SDK, these tools will be in the Microsoft Visual Studio .NET 2005\SDK\v1.1\Bin or \Program Files\Microsoft Platform SDK\Bin\ directory respectively.
The tools that are most useful for code signing are:
- MakeCert.exe: Generates a test X.509 certificate (CER) containing your public key and .pvk file containing your private key. This certificate is only for internal testing purposes and can't be used publicly.
- pvk2pfx.exe: Creates a Personal Information Exchange (PFX) file from a CER and PVK file. The PFX contains both your public and private key.
- SignTool.exe: Signs file using the PFX file. SignTool.exe supports signing DLL, EXE, MSI, and CAB files.
Note: You may find old references to the SignCode.exe tool, but this tool is deprecated and is no longer supported - instead you should use SignTool.exe
Example using a test certificate
The following steps demonstrate how to create a test Code Signing certificate, and sign the Direct3D sample called BasicHLSL.exe using this test certificate:
Create a Test CER and PVK file using MakeCert.exe
The CER and PVK files contain your public and private keys respectively and can only be used for internal testing.
makecert.exe -sv MyPrivateKey.pvk -n "CN=MySoftwareCompany" MyPublicKey.cer
Create a PFX file from the PVK and CER file using pvk2pfx.exe
The PFX file combines your public and private key into a single file format.
pvk2pfx.exe -pvk MyPrivateKey.pvk -spc MyPublicKey.cer -pfx MyPFX.pfx -po your_password
Sign your program with PFX file using SignTool.exe
You can also specific all the options on the command line like so:
signtool.exe sign /f MyPfx.pfx /p your_password /v BasicHLSL.exe /t URL_to_timestamp_server
Note that the last switch and parameter are used to timestamp the signature. Time stamping prevents the signature from becoming invalid when the certificate expires. The time stamp service URL will be provided by the CA. Code that is signed but not timestamped will not validate after the certificate expires. There, all publicly released code should be timestamped.
Verify the program is signed using SignTool.exe
signtool.exe verify /a /v BasicHLSL.exe
The output log should show your certificate attached but it will also say that it is not trusted since it is not issued by a CA.
Using a trusted CA
To obtain a trusted certificate, you will need to apply to a Certification Authority (CA) such as VeriSign or Thawte. For a complete list of trusted third-party certificate authorities, see Microsoft Root Certificate Program Members. Microsoft doesn't recommend any CA over another, but if you want to integrate into the Windows Error Reporting (WER) service, you should consider using VeriSign to issue the certificate because accessing the WER database requires a WinQual account which requires a VeriSign ID. More registration details on WER are explained here ISV Community Center: Windows Error Reporting.
After receiving the certificate from the CA, you can then sign your program using SignTool.exe and release your program to the public. However, you must be careful to protect your private key contained in your PFX and PVK files. Be sure to keep these in a secure location and not locally on the developer's machine.
Integrating into the daily build system
To integrate code signing into a project, you can create a batch or script to run the command line tools. After the project is built, execute SignTool.exe with the proper settings:
signtool.exe sign /f MyPfx.pfx /p your_password /v BasicHLSL.exe /t URL_to_time_stamping_server
Again, make sure you take extra caution in your build process so access to the PFX and PVK files is restricted to as few machines and users as possible. For best security practices, the developer should only sign with the test certificate until they are ready to ship. Additionally, sensitive information like the private key should be kept in a secured location, such as a locked area like a safe, and ideally in a hardware crypto device such as a smart card.
Another layer of protection is to use Microsoft Authenticode to sign the MSI package itself. This helps protect the MSI package against tampering and accidental corruption. To add code-signing to a MSI package, in MSI project's Properties Page check the Authenticode signature box. Then fill in the Certificate file, Private Key file, and Timestamp server URL fields with the appropriate information.
You can also integrate Authenticode signing into a Wise for Windows Installer or InstallShield package. With Wise for Windows Installer, from the Installation Expert screen open the Distribution drop down and select Digital Signature. Select the Add a Digital Signature radio button and fill out the appropriate fields. With InstallShield, use the Release Wizard and check both Sign Windows Installer Package and Sign Setup.exe. Then fill out the appropriate fields.
Revocation
In the event that the security of the private key is compromised or some security-related event renders a Code Signing certificate invalid, the developer has to revoke the certificate. Not doing so would weaken the integrity of the developer and the effectiveness of code signing. A CA can also issue a revocation with specific time. This will invalidate any code signed and time stamped after the revocation time, but will allow any code time stamped before the revocation date to continue to validate. This includes code in different applications signed with the same certificate.
More information
More information on these tools and process can be found on MSDN at:
Authenticode Overview and Turtorials
Frequently Asked Questions About Authenticode
Summary
Using Microsoft Authenticode is a straightforward process. Once a developer has obtained a CER and created a private key it is a simple matter of using the tools provided by Microsoft. The developer can then enable important Windows Vista features such as parental controls and let customers know that your product comes directly from its rightful owner.