Rob Smyth

Friday, 1 August 2014

Keeping an Authenticode certificate secure for signing applications

Your working for a small/medium company and the boss wants you to secure the application with digital signing ... your not in control of IT security, how are you going to ensure that the private keys are secure?

Background

Cyber security is becoming more important to software development as the risk of attack become better understood and more prevalent. Basic .Net application security requires both signing the application with an Authenticode digital certificate and strong name signing the assemblies.

Authenticode signing allows users to identify that the application came from "us" and has not been modified by somebody else since we signed it. Critical for user who download installers and is superior to MD5 checks.

Strong name signing is about ensuring that referenced assemblies have not been replaced.

Both Authenticode and strong name signing are based on the security of private keys. If an attacker obtains a copy of the private key they may impersonate your company without the end user knowing.

Obtain a computer with a new OS install that is normally stored, turned off, in a secure location. Purchase and download the Authenticode certificate onto this computer being careful to minimize network connection to placing the purchase and downloading the certificate only. Minimize the attack surface by keeping this secure PC normally off-line.

Export the certificate's private keys to secure devices (e.g. IronKey). Such a device will self-destruct after N attempts making attacks near impossible.

Delete the certificate from the PC.

Building a release:

After testing binaries (testing application), sign assemblies and complete strong name signing on the secure PC with the Authenticode private key available on an inserted USB stick.

Note: Holders of the secure USB devices should only ever open the device on the secure PC.

Best practice is to use tested binaries from a build server (artifacts) such as TeamCity and use an installer build script that recognises key available on USB device.

Using this approach:

the private key is only vulnerable to the network during the installer build.

unsigned binaries can be testing without signing.

the PC used to perform the final installer build/signing is clean and normally off-line.