How to secure a certificate internally

Question

Say I have a certificate which I use to sign the software I ship. This happens in the (daily or more) build on the buildserver (Windows machine). Easiest solution would be to put the certificate file (pfx) on the buildserver and just use it there.

But like this, it could be stolen by either any guy in the company (think .. frustrated leaving guy) or a virus or whatever. This might lead to a disaster.

Currently the certificate is stored in the certificate store as "unexportable", which should be a little more safe. But how safe is this "unexportable" thing really? The server is a VM, so I guess someone could just copy the the whole thing, take it with him and sell it, or use it to sign anything.

Of course anyone with access to the buildserver could use it to sign anything on there, but I guess there isnt really a way to fix that. (And going to the office to signing malware (or whatever) seems much more unlikely than just selling the certificate or something like that, so it is assumed to be way more unlikely)

So my questions are:

• How safe is that "unexportable" thing really?
• Should it be put on a hardware machine to make it harder to steal/copy the whole thing?
• Is there a better/more secure way to handle this?

Answer 1

"Unexportable" means that the dedicated functions from the operating system will refuse to export the private key. However, it is of course there; this is just software, so the private key, when used, necessarily exists at some point in RAM with all its structure. The marking of the key as "non exportable" is a security system only against attackers who do not have administrator rights, and must act within the constraints of the API. Otherwise, export is rather easy. For that matter, a simple whole-system backup would be sufficient to obtain the private key.

To make key storage robust against local attackers (people who have access to the machine, and are technologically competent), you need a Hardware Security Module. This is an expensive piece of hardware, which will never give away a key which has been entrusted to it; it will actively destroy the keys if it detects a physical breach. Moreover, it will log all private key usages. Someone accessing the HSM physically could still obtain as many signatures as he wants, but they all will be logged and will not have the key itself (so he won't be able to sign afterwards). A cheaper (but somewhat less robust) version would be a smart card.

The usual method for securing access to code signing keys is to have two keys; a "development key" which is used for development, and a "production key" which is used only when an actual product is about to be shipped. Developers' machines are configured to accept the development key as valid, so that developers may work with code signed with the development key, but of course only the production public key is deployed in the user base. The idea is that signing with the production key should be sufficiently rare that you can do that in a non-automated way, under physical scrutiny of the management, and using dedicated hardware (e.g. a smart card which is normally kept in a safe).

(When using special hardware to store a private key, backups can be an issue. You should take care to either keep a safe copy of the key somewhere, or to be able to obtain a new one within a short notice.)