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.
How build applications and keep certificates secure
Assumptions:
- You network's security is not "perfect".
- You do not want to expose the key to all staff (principle of least privilege) ... they probably do not want to have access anyway.
- You would like separation of duties (optional with the process here).
- All encrypted storage is breakable.
- 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.
- 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.
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.
See also: Oracle security overview.