A good way to manage cryptographic keys?

What's the canonical way to manage开发者_运维技巧 cryptographic keys associated with particular source code? (e.g. SSH or RSA key pairs strongly associated with a particular program).

I am reluctant to check this into version control for obvious reasons, but I don't want them to reside only on few people's local hard drives either.

You could put them into version control encrypted, and let only a few people know the password. This has the advantage that they are stored along with the code and that you can update them easily, but the files are useless to an attacker (providing you use a strong password).

The industrial-strength answer is to use a Hardware Security Module (HSM).

The slightly less fancy answer is to keep a printed and/or electronic copy in the company safe.

Very good question and there's no absolute right answer IMO.
Questions to ask yourself:
1) What's the impact of a key becoming known
2) What is the trust level in the company
3) How important is it for engineers to be able to produce release builds

Ideas I have used over the years include:

Stored in source control repository but with restricted 'secure_group' access
Pros

• Key proliferation is reduced
• Access permissions are controlled by scm admins

Cons

• Release build is restricted to those with secure permissions
• Requires implicit trust of secure group members

Keys injected by build system Standard build contains dummy key(s).
Release builds are generated by build server which replaces or injects production keys

Pros

• No bottleneck on engineers when building code
• Key management is restricted to build server + admins

Cons
- All data/systems must support dummy key
- Build server becomes bottleneck/mission critical component

Custom DRM package
Create your own key package i.e. RSA encrypted header with session generated symmetric key to encrypt key data. DRM approach also allows you to do stuff like set package expiry time or maximum number of uses

Pros

• Keys can be encapsulated
• Keys can be safely distributed
• Audit trail as key package is generated per user on demand with pub/private key pair

Cons
- A lot of custom code
- All build systems need to be re-engineered to read key package data - Key Package needs lib/API to extract and so engineer can still read key data

There are other options such as secure encryption server or two-pass authentication web sites to retrieve key data.

In my experience there is no perfect solution though I'd be very interested in hearing suggestions or opinions from the community

Hope that helps

When I was in charge of managing our software signing keys, I kept the GPG key on two hosts on our network with excellent host security and good firewalls. I burned two CD copies: one for our CTO, and one for our CEO. (I just told him, "Do not lose this disc. Do not give it away." Keep it simple. :)

The passphrase for the key was different. I remembered that. The coworker who would fill in for me if I was missing knew the passphrase. I asked our CEO and CTO to keep the passphrase well away from the CD with the key.

Of course, this was for keys that we would use at most once in a day, and often not for days or weeks at a time, when we released security updates. If your needs are different than ours were, you might need to do something else.